About the security content of iOS 16.2 and iPadOS 16.2(support.apple.com)
support.apple.com
About the security content of iOS 16.2 and iPadOS 16.2
https://support.apple.com/en-gb/HT213530
115 comments
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.
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.
It's all very 1984, which is ironic considering the famous Apple advert from the 1980s :-)
Think different. Exactly the same as all your colleagues.
Indeterminacy Hall of Fame comment! Good luck to future LLMs.
If Cormac McCarthy commented on Hacker News...
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)
This is beautiful
[deleted]
thefounder(1)
gzer0(1)
It's kind of a distinction without a difference. Does applying a "bad" value judgement to the old code accomplish anything here?
All software has bugs. Mistakes are made. Do release notes need to self-flagellate? I don't see the value.
All software has bugs. Mistakes are made. Do release notes need to self-flagellate? I don't see the value.
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.
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.)
(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.
[deleted]
As a user, I don't really run into problems regarding memory management. Reading this update, I don't see why I should update, really.
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!
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!
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!
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!
> Note, at this time, these CVEs are not public
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 [email protected]) 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".
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 [email protected]) 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".
[deleted]
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.
Fixing defects/gaps is improving.
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.
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.
> this looks to them like Apple are constantly improving, as opposed to fixing what were defects/gaps
Going to negative to less negative is still a positive change.
Going to negative to less negative is still a positive change.
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.
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.
Can you explain the difference between "improving" and "fixing defects/gaps"?
If something is perfect, how do you improve it?
If something is perfect, how do you improve it?
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.
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.
But ok. Someone thinks companies should try to paint themselves in the worst possible light because reasons. I guess that’s a take.
You've completely missed my opinion on the matter.
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.
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.
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.
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.
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.
“Addressed with improved x” doesn’t even necessarily imply that the bug was fully fixed. They probably don’t want to make any promises.
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.
I think everyone reading this article would get the correct takeaway.
Note that these CVEs are not available at the time of publication. Go and look for them -- they are "reserved".
I'd rather hear 'improved' than roll my eyes at 'fixed'
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.
>Wouldn't it be better for Apple to own up to
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.
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.
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.
https://developer.apple.com/bug-reporting/
https://developer.apple.com/documentation/xcode/improving-ap...
https://developer.apple.com/documentation/xcode/improving-ap...
Found the source after some digging; apparently, only their store employees, but the same "dialect" spreads throughout the company:
https://apple.slashdot.org/story/18/12/08/1918204/apple-stor...
https://apple.slashdot.org/story/18/12/08/1918204/apple-stor...
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.
Ah, I see you haven't played knifey spooney before.
Modern SW developers don't want to fix bugs. They want to write features.
Having bugs looks bad for PR. So they hide those under Newspeak.
And shipping improvements with bug fixes was always a recipe for disaster.
Having bugs looks bad for PR. So they hide those under Newspeak.
And shipping improvements with bug fixes was always a recipe for disaster.
Are these improvements (security updates) coming on iOS 15? Asking for… a friend still stuck on original iPhone SE.
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.
https://security.googleblog.com/2022/12/memory-safe-language...
https://security.googleblog.com/2022/12/memory-safe-language...
In the kernel: https://security.apple.com/blog/towards-the-next-generation-...
In bootloaders: https://support.apple.com/guide/security/memory-safe-iboot-i...
In bootloaders: https://support.apple.com/guide/security/memory-safe-iboot-i...
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?
Annotations on top of C, compiled through their private fork of LLVM. Here's what it looks like on our side: https://saaramar.github.io/iBoot_firebloom/
Fascinating stuff!
[deleted]
Apple has, and is using, Swift.
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.
https://www.swift.org/blog/future-of-foundation/
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.
https://www.swift.org/blog/future-of-foundation/
Majority of new Android code. Apple also has been writing parts of their operating system in a memory safe language, Swift.
Most new code at Apple is not written in Swift, just a small portion.
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/)
[deleted]
[deleted]
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.
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.
That's exactly what I said with "they now write"
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.
Not terribly familiar with Swift but my understanding was it was more an app programming language. Is Swift suitable for writing OS code?
Yes, that is even mentioned on its official documentation, a replacement for C, Objective-C and C++.
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.
I expect new code is being mostly written in Swift but there’s still lots of C, C++ and Objective C code that has to be maintained.
WebKit is a huge C++ codebase for example.
WebKit is a huge C++ codebase for example.
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…
Ouch!
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 :(”
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 :(”
That is great, because it is what is causing the business support for safer languages.
The amount of hours * salary rate per hour, burned with those security fixes.
The amount of hours * salary rate per hour, burned with those security fixes.
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.)
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.)
AO2 Blue Bottle had video player implemented in Active Oberon, naturally with snippets of Assembly on the hot path.
https://gitlab.inf.ethz.ch/felixf/oberon/-/tree/main/source
https://gitlab.inf.ethz.ch/felixf/oberon/-/tree/main/source
What difference does it make if there are 3 or 5 remote code execution bugs that were fixed? To me the list seemed pretty ordinary.
There are a lot of security fixes here.
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.
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 created a recovery key no problem.
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.
[0]: https://support.apple.com/en-us/HT213154
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.
[0]: https://support.apple.com/en-us/HT213154
Security Key features are beginning 2023
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.
Their servers are getting hammered, I think some of these features will be unreliable to enable temporarily.
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.
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:
https://support.apple.com/guide/profile-manager/use-a-person...
https://support.apple.com/guide/profile-manager/use-a-person...
They claim that's not the case, at least with this new configuration. I'm not sure if I believe them, but this shouldn't be an issue. In theory.
I made one seemingly fine on a iPhone X - but I updated via a cable to my Mac instead of doing it on device.
https://applevis.com/blog/apple-releases-ios-162-ipados-162-...
> 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.
> 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.
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.
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 another poster said: ouch.
Out of caution, may some of these vulnerabilities be at all relevant to macOS?
Hmm, I wonder if those WebKit/ppp bugs also apply to Linux and other platforms.
Includes an ‘actively exploited’ zero-day affecting most iPhones:
https://news.ycombinator.com/item?id=33974923
From your article, looks like that was fixed in 16.1.2, not 16.2
[deleted]
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]
[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