Interesting how all of these "security content" documents frame the bug fixes as "improvements." For example, in this one:
This issue was addressed with improved data protection.
An out-of-bounds write issue was addressed with improved input validation.
A logic issue was addressed with improved checks.
The issue was addressed with improved memory handling.
Makes it sound like data protection, input validation, checks, and memory handling were fine. But now they are better. Whereas the truth is that they were bad and led to data leaks and remote code execution.
As it goes with improvements, they keep coming.
Wouldn't it be better for Apple to own up to the fact that these defects are indeed defects, and be transparent about what measures they are implementing that prevent such defects from being added to the code base or from being exploited?
Google wrote about the former a couple weeks ago[1] and Apple itself is not doing badly in the latter department.[2]
Remember that Apple is a global empire. If you have met any of their people, they learn a kind of culture language which diverts and uncenters themselves where no one person other than Cook can be seen to represent it. Understanding their brand language starts with the idea that Apple is an ideal of perfection, and beneath it are the ideals of harmony and flow. As an ideal, Apple does not have defects. Only things and maybe the past can have defects.
These other things like bugs and vulnerabilities are external to its perfection, and so they originate elsewhere, maybe in the past, maybe as something random, but certainly something devoid of meaning when compared to the ideal and its experience. Individual products are not Apple, because they are not perfection, but they align to it, and perfection is what makes it always seem just out of reach. The Apple experience exists above and over the material bounds of memory handling and input validation, so these things are external, and in the brand language, they are only ever allowed to exist in the past. By way of example, this is why their security advisories can come off as weird to analysts who confront and solve things.
The best writers speak the language of memory, and a trillion dollar company probably has more than a few of them. Consider that 80% or more of what you believe about reality comes through one of their products, and you are in-effect entranced by them. Their responsibility is to sustain this experience of hypnotic comfort and perfection. The advisory language is reduced until there is nothing left to remove, then calibrated to cause nothing more than a small ripple in your bliss.
This comment would seem completely absurd if I didn’t work in a massive corporation and see precisely what you mean every day. On the one hand, they’re ultimately just plain old full of shit, but there is definitely a subtle, structural dilution of language that goes on that serves to divorce cause and effect. But it’s not an Apple thing—most large corporations are like this, just not quite as zealous as Apple employees tend to be.
Very well put. And I feel things become a self-reinforcing cycle when people begin buying into the narrative from within, come to believe that the corporate line is the truth, etc. (love the name btw)
And yet, they keep imposing their view of the world upon everybody else with complete disregard to what they might have preferred. Like it's the only way.
Unfortunately the rest of the way cannot vote out the US's interference.
I think you detracted from the OP. Apple's views are on its products. It doesn't care about the rest of the world (i.e android) so your comment it's a bit misplaced.
That being said I keep hearing that argument that some people don't like democracy(i.e like the U.S) and would rather live under an authoritan and conservator rule so we should let them be ruled that way. But how could they choose if they are not given a choice? Do women in Afghanistan prefer not to go to school? Let them vote and for that freely. They could simply not go to school after all.
Yeah, the School of the Americas was all about giving people choice and democracy right? Oh wait, it was actually an instrument to depose democratically elected governments and installing US-friendly bloodthirsty dictatorships instead!
Operation Condor, the lawfare coups of the 2010s...
All in the name of democracy and choice for the peoples affected, right? And they chose to have that interference, right? Napalming Korea to the north of the 38th parallel was their choice, right? Syngman Rhee was the democratic leader of choice for the ones to the south of that parallel, right? Yeah...
> I think you detracted from the OP. Apple's views are on its products. It doesn't care about the rest of the world (i.e android) so your comment it's a bit misplaced.
You mentioned the US being able to vote out bad leadership and abuse of the ruling party. I just responded to that.
What the U.S does to other countries to protect its interests is another story. Of course it sucks to be the little guy, especially when you forget that power still matters in this world and you piss off powerful countries/interests.
U.S does not shy (like all the powerful countries) to say that it will protect its interests regardless what you think is right or wrong.
That doesn't mean it's okay to opress your own people and give them no choice to replace the leadership(i.e China, North Korea)
Oppressing own people, bad. Oppressing other people as long as it's to protect US interests, good. Getting other governments to oppress their own people as long as it's to protect US interests, good.
I think “improved” also subtly implies that there was something in the code to do A, A has been improved so it no longer breaks in a specific way, and A could still be vulnerable to other unrelated attacks.
The thing I just improved is subject to future improvement. Subtly different than saying “fixed the input validation routine”, which implies some finality, or overcommitment.
Some still might interpret that as Apple using CYA language or a lack of admission, but to me it seems like a fairly pragmatic statement of what seems like reality.
It seems to me that "improved" carries the same type of uncertainty as "fixed" would. If the "improvement" didn't actually fix the security issue, then was it really an improvement?
(To be clear, it may have been, but we don't know without actually seeing what change they made to the code.)
In large organization, you'll see people move to verbiage like 'improved' because it's true without the implication that 'fixed' has which directly implies that the previous implementation was 'broken'. I am with Apple on this, they 'improved' the software.
Apple's writing style is unclear. It is poor for the intentional obscurity. Granted, it is a small issue in the context of the rest of the document. But the problem remains: The writing is intentionally obscure!
This hides the severity of the problems the patch fixes. The word "fix" is nowhere on that page. Presumably, Apple are releasing these poor-quality release notes in order to protect their public brand. Those corporate objectives are coming at a cost of writing quality and clarity.
Note, at this time, these CVEs are not public, so the savvy user can not search them up themselves.
I think patch notes are important, and reasonable effort should be made to make them clear. Instead, effort was made to obscure. Clarity should be the default!
I'm not sure what the lag is, but from what I've seen all Apple CVE's are made public at some point. The last one I got before this bunch (from security-annouce@lists.apple.com) was a month ago (relating to iOS and iPadOS 16.1.1 addressing a libxml2 integer overflow - CVE-2022-40303). If you look up that CVE at mitre.org, it's no longer marked as "RESERVED".
It matters less when the impact is clearly stated, but often you'll find an update claiming that it "improved stability" and you have to guess whether it's something you don't need if you haven't encountered stability problems, or a critical security update.
It's a matter of perspective. When you run a business, all of your public communication is marketing communication. That's why they're phrased in the positive, and they're not necessarily highlighting the shortcomings they're aware of.
Exactly, to the majority of the population, this looks to them like Apple are constantly improving, as opposed to fixing what were defects/gaps. And that's exactly what Apple want, which is how you run a business.
My point is in relation to the post above, where its about Apple's marketing. It is improving, but it looks different to the average consumer when you say ""we have improved the security of x" as opposed to "we have fixed these existing defects that did x".
In relation to someone being annoyed that Apple doesn't openly say the former. It's because of their marketing and image that they say the latter, it always have been.
My point is in relation to the post above, where its about Apple's marketing. It is improving, but it looks different to the average consumer when you say "we have improved the security of x" as opposed to "we have fixed these existing defects that did x".
In relation to someone being annoyed that Apple doesn't openly say the former. It's because of their marketing and image that they say the latter, it always have been.
To the average consumer they like seeing the former, but for tech heads we prefer to see the latter.
I fully expect that the average consumer is not reading any of these notes, and either has automatic updates on, and stuff just magically happens at some point, or has them off, and then wonders why shit breaks 2 years after their last update. The segment of the population that has auto updates off yet waits to read the release notes to make an informed choice regarding updating, is very small. And I'd hazard a guess most of us are on this thread.
My point is in relation to the post above, where its about Apple's marketing. It is improving, but it looks different to the average consumer when you say ""we have improved the security of x" as opposed to "we have fixed these existing defects that did x".
In relation to someone being annoyed that Apple doesn't openly say the former. It's because of their marketing and image that they say the latter, it always have been.
I still don’t understand it. Like, my new toothbrush (“Now removes more plaque!”) should disparage the old model (“fixed bristle design flaw that left pockets of plaque on occlusions near front of mouth where interior bristles were too short”).
But ok. Someone thinks companies should try to paint themselves in the worst possible light because reasons. I guess that’s a take.
Apologies, I could have been more clear that I was in fact expressing my disagreement with the framing that you relayed, and understood it was not you personally I was disagreeing with.
I still don’t understand the difference between "improving" and "fixing defects/gaps". There might be a difference in tone, but I see no difference in information content.
Please read my comment with the context of the original comment, rather than reading mine in isolation.
The user was saying that Apple were wording their fixes of large gaps as simply improvements to the technology, rather than calling out that they had fixed what may have been a significant defects/issues.
My point is that you're right, there may not be a difference, but in tone it is different and that is why Apple have worded it that way. Apple is notorious for framing everything in the most positive light it can, which may not necessarily convey the severity of the gaps/defects that were improved.
I feel like I'm pulling blood out of a stone here.
I get all of that. I just don’t see why this is an issue. Far as I can see the accusation is that Apple communicates in a manner less consistent with people who contribute to open source projects and more consistent with just about every major consumer-facing corporation on the planet — then yeah, you’re completely right. I’m just trying to work out where the controversy is. Or why it matters.
It only mattered because the original commenter further up complained because they wanted Apple to communicate more like as you say, open source.
Myself and another were just clarifying why it is that Apple communicates the way they do, whether it’s wrong or right. I didn’t have an opinion on the matter.
I don’t think there’s any confusion or ambiguity here. This is a page solely about security fixes in updates. They mention (but don’t link, ugh) the CVEs.
I think everyone reading this article would get the correct takeaway.
To my reading, these are release notes, not a blog post. Their job is only to describe what changed in this release. Calling an improvement an improvement seems pretty straightforward to me.
It's deliberate and resembles the attitude of "toxic positivity" that is sometimes brought up here; I remember reading an article a long time ago about Apple prohibiting words such as "bug" and "hang". IMHO "issue" and "addressed" are also obfuscatory. They could've just said "fixed a bug", but Apple believes it is too perfect for that.
And if the press release stated that flaws in input validation had been fixed, would that not be an improvement? Or would it be sufficient to simply say ‘bug’ rather than ‘issue’. I’m not sure the bug/issue is with the word ‘improvement’.
> Makes it sound like data protection, input validation, checks, and memory handling were fine. But now they are better. Whereas the truth is that they were bad and led to data leaks and remote code execution.
Ah, I see you haven't played knifey spooney before.
What is Apple doing about these non stop memory safety bugs? Google has put out a post about how they now write the majority of Android code in memory safe languages including 1.3 million lines of production Rust. While Apple hasn't said anything as far as I'm aware.
I would love to see details of iBoot. How they built a memory safe bootloader with just "a modified C toolchain" is a pretty important detail. Did add they another language to the toolchain or add a special --memory-safe flag to a forked C compiler?
I actually think a lot of their new projects are written almost exclusively in Swift. There’s a lot of existing code that would need work to embed Swift into, though. (They’re working on it: https://www.swift.org/blog/future-of-foundation/)
No, google wrote a blog post about how they're moving their new code to safe languages. The vast majority of Google's code is in C/C++, and will be for the foreseeable future. The same is true for Apple - there's a huge amount of existing C/C++, and new code is increasingly being written in Swift.
That blog post was about Android, its use of Java, Kotlin and now Rust (since Android 12), mainly used to rewrite Bluetooth stack and the new virtualization framework in Android 13.
Any NDK user painfully knows how castrating the whole experience is, to access anything that doesn't have to do with graphics or real time audio.
in that case you can look at the last series of years of WWDC with apple driving swift for developers, and swift's adoption by apple by increasing amounts of the OS. Which seems like the equivalent, only not in blog form.
Swift is a very powerful and robust language. I would expect that they keep going further down the stack with it but the problem will always be, "is it worth investing in a language refactoring on an existing codebase?". I presume all but the lowest level (or server-side) new code is in Swift at Apple nowadays.
For this batch... most of the memory safety issues look to be in kernel code or adjacent, followed by Safari/Webkit. The Android Linux kernel is still pure C (for now), and I'm pretty sure new Chrome/Blink code is still primarily C++. The codebase as a whole certainly is…
That felt like a longer-than usual list of bugs, especially the memory mgmt bugs leading to arbitrary code execution. And a sizeable number of remotes (if you include webkit in that category.)
I honestly don’t know what to feel; ”great that they fixed so many!” or ”yikes, there are probably millions more like this :(”
For some types of apps, sure. But if you look at the list, the ones that sting the most are kernel or video parsing errors or similar. I am just not seeing these being implemented with anything else than an efficient, low level programming language. At least not for the foreseeable future.
But what it may do, hopefully, is getting rid of all that audio/video/photo stuff from the kernel. One has to ask why a video encoder can leak kernel memory in the first place. (This was rhetoric question, we all know why. It is just not sustainable to put more and more stuff into monolithic kernel as you add more silicon to solve some CPU/GPU intensive problems because it is just easy.)
It seems reasonable to assume that next month there will be a similar set.
Many of the vulnerabilities are remote exploitable, sometimes even on a locked device.
Only one such exploit is needed for someone to be able to steal your data from a locked lost phone - either by knowing an exploit before Apple does, or by keeping your phone in a metal box for a month before exploiting it.
Anyone else having issues creating a recovery key for their device? I have tried several times to do so since updating to 16.2 but I can’t get the code to verify.
I'm confused about the Security Key for 2FA situation, since I can't find that anywhere on iOS. On the AppleID website, it mentions it, but the "learn more" link 404s[0], and the "continue on device" button errors out.
I guess they're working on rolling this feature out on the backend still.
I attempted to create a recovery code on my ipad. I tried bout 5 different codes, and I could never get them to verify. I had to enable/verify the recovery code on my macbook, after which it worked first attempt. Something's up with the ipadOS/iOS versions.
You would think generating and verifying a recovery key wouldn’t need server access, but I’m getting the same thing as OP on an iPhone 13 mini. I wonder if one of my PiHole lists are blocking it?
I believe they also keep a copy of your recovery key. Apple touts privacy and security but most people I know that use Apple just repeat whatever they claim in their press releases, and have no clue if their device is actually secure.
For someone with luks2 in the username you sure have a lack of understanding about encryption.
Why would it be so hard to believe that your recovery key is hashed and salted like every other password? You can't view your key after creation, you have to regenerate it. Do I really need to pull out Wireshark to verify this for you?
Advanced data protection is explicitly removing Apple as a holder of your keys, it's not re encrypting anything, it's not new encryption. The entire process is just deleting the key that was already stored on their servers anyway. How would it be in Apple's interest to keep your recovery key after press releases and multiple warnings saying you're on your own for recovery.
Microsoft Windows has the option to upload your BitLocker recovery key to your Microsoft account. I was trying to understand why Apple needed to ping a server for a recovery key. Oh, look... they do have that feature afterall:
Are you also having issues? I’m troubleshooting the issue with Apple Support right now but not having any luck. They said they are going to open a ticket with the engineering team.
No. But why would you expect that? .0 is for the general population but if you're a power user with a mix of libraries and applications and configurations plugged together over the prior decade to make your 'World', you need .1 or .2.
Your post seems to imply that people with disabilities are not part of the "general population". Also, they are considered power users and if something they need doesn't work, they are on their own? Pretty harsh, but its a free world. Everyone is entitled to their opinion.
Apologies, didn't notice the link there. Agreed that the 3 'moderate' bugs when it comes to accessibility probably should have been a launch blocker for the .0 release (presuming they were reported before the release).
I don't consider an OS being accessible a Power User thing - it's just a core requirement since those with disabilities are part of the "general population" and their standard usecases should be satisfied before the GM.
As it goes with improvements, they keep coming.
Wouldn't it be better for Apple to own up to the fact that these defects are indeed defects, and be transparent about what measures they are implementing that prevent such defects from being added to the code base or from being exploited?
Google wrote about the former a couple weeks ago[1] and Apple itself is not doing badly in the latter department.[2]
[1] https://security.googleblog.com/2022/12/memory-safe-language...
[2] See Luca Todesco's talk from October: https://www.youtube.com/watch?v=8mQAYeozl5I