About the security content of iOS 16.2 and iPadOS 16.2
support.apple.com
support.apple.com
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.
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
Going to negative to less negative is still a positive change.
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.
If something is perfect, how do you improve it?
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.
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.
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.
But ok. Someone thinks companies should try to paint themselves in the worst possible light because reasons. I guess that’s a take.
I agree with you and that was my point. Tt was the original poster who thought companies should paint themselves in the worst possible light.
I was supporting another commenter who simply explained why it is that companies paint themselves in the best light.
You need to have read my comments in relation to what I was replying to, rather than in isolation.
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.
All software has bugs. Mistakes are made. Do release notes need to self-flagellate? I don't see the value.
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.
(To be clear, it may have been, but we don't know without actually seeing what change they made to the code.)
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".
Clearly there's already something dealing with bad memory and Apple just made it a bit better, surely this isn't worth rebooting my phone for!
I think everyone reading this article would get the correct takeaway.
It's unsatisfying, but the answer to this has always and will always be no. There is never an upside for them to disclose any more than they have to.
https://apple.slashdot.org/story/18/12/08/1918204/apple-stor...
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.
Ah, I see you haven't played knifey spooney before.
Having bugs looks bad for PR. So they hide those under Newspeak.
And shipping improvements with bug fixes was always a recipe for disaster.
https://security.googleblog.com/2022/12/memory-safe-language...
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.
WebKit is a huge C++ codebase for example.
There was an announcement recently that Foundation was moving to be written in Swift and not C/C++/Obj-C (I’m not sure how much of each it was).
This means a whole host of conversions and memory allocation and such will be in a safe language, underpinning everything.
Including Objective-C programs.
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 :(”
The amount of hours * salary rate per hour, burned with those security fixes.
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.
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.
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.
https://support.apple.com/guide/profile-manager/use-a-person...
> At the time of writing, we are aware of the following new bugs ...
I wonder if I will ever be able to install a .0 iOS release without breaking my world.
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.
> Available for: macOS Ventura
> Impact: Shake-to-undo may allow a deleted photo to be re-surfaced without authentication
Can you shake a Mac to undo?