8 ms·

A survey of recent iOS kernel exploits

120 points by edmorley 6y ago

robocat 6y ago
Great summary list near end of article of the various mitigations used by iOS - there is quite a few hardware protections implemented within the processors themselves. Android is less of a monoculture, but also has less opportunity to tune the processor to include strong hardware mitigations against whole classes of vulnerabilities.
- stefan_ 6y ago
  While iOS seems to pioneer every mitigation technique ever described in the literature, they also shipped ancient versions of C image parsing libs (OpenEXR), have an endless stream of remote code execution vulnerabilities from their peculiar serialization schemes and all the other issues you would expect from the use of native ObjC. Their commitment is squarely to mitigating issues that threaten the walled garden (and therefore the kernel), not so much userspace.
  - RL_Quine 6y ago
    I don't think that's really fair, those classes of exploits (ie, libtiff / jailbreak.me) were around a decade ago now.
    - tsbinz 6y ago
      https://googleprojectzero.blogspot.com/2020/04/fuzzing-imageio.html https://googleprojectzero.blogspot.com/2020/04/fuzzing-image... isn't a decade old, on the contrary.
  - pjmlp 6y ago
    Solaris on SPARC did hardware memory tagging much earlier than iOS.
    - saagarjha 6y ago
      iOS doesn’t actually do hardware memory tagging at all.
      - pjmlp 6y ago
        Yes it does after iPhone X, aka pointer validation in Apple speak.
        saagarjha 6y ago
        Pointer authentication is not hardware memory tagging. (Also, PAC shipped with iPhone XS.)
        pjmlp 6y ago
        Playing word games when the actual technical outcome for preventing memory corruption is the same one.
        saagarjha 6y ago
        No, they are entirely different features. Pointer authentication is largely a control-flow integrity feature. Hardware memory tagging attempts to prevents arbitrary overwrites/memory corruption, even to data. There are dozens of other features that prevent memory corruption and it's not really "playing word games" to distinguish between them.
        pjmlp 6y ago
        It is still conceptually the same from my point of view, and the data structures used by the hardned runtime.
        saagarjha 6y ago
        I assume you're not talking about this: https://developer.apple.com/documentation/security/hardened_runtime https://developer.apple.com/documentation/security/hardened_...? And to your other point: the difference between these things do matter because they have entirely different semantics and protect against different things, although the overarching goal of preventing undesired operation is the same. Taking the metaphor one level up to apply to computer science rather than security, this is like saying that the borrow checker and asserts are both the same from a certain point of view because they both help prevent bugs. Which is true, of course, but when you're talking about a programming language's safety features saying something like "C can prevent use-after-free because of its borrow checker" is not correct nor can you make it relevant by saying something like "yeah but C has asserts and they also help prevent bugs so from my point of view I think you're being pedantic".
  - amluto 6y ago
    The issue doesn’t seem to be ObjC per se. It’s the use of a facility that tries to transparently serialize an object in any rich language. Python pickle has the same issue, although it’s arguably worse in Python. The solution is to abandon the whole approach — these systems should not be used across trust boundaries. Apple should create iMessage v2 using a real serialization system (protobuf, JSON, XML, ASN.1, etc) and deprecate the old scheme. It’s surely possibly to write a safe but non-extensible deserializer for the old protocol if compatibility is needed.
  - saagarjha 6y ago
    iOS also sometimes creates their own mitigation techniques. Sometimes these are quite strong but often they are…not really mitigating anything; in rare cases they make the situation worse. Shipping every mitigation under the sun is not necessary a good idea.
  - dontbenebby 6y ago
    >Their commitment is squarely to mitigating issues that threaten the walled garden (and therefore the kernel), not so much userspace. As a practical matter, doesn't this mean if I'm confident in my ability to avoid phishing messages, iOS is better? Anything that "roots" a phone can also run roughshod, turn on my mic, grab signal messages stored locally, etc, correct? What I'm getting at is a phone in a walled garden + a laptop that's open source might be the best way to get the security of the walled garden and the utility of open source.
    - stefan_ 6y ago
      I'd argue it is the opposite. The people that want to grab your Signal or WhatsApp messages can often do so by simply sending your some picture or specially crafted message; it's only the people that want to run their own software that need to break all the kernel defenses and 'root' the device.
    - fomine3 6y ago
      "confident in my ability to avoid phishing messages" is not a good way for security.
      - dontbenebby 6y ago
        I literally designed antiphishing trainings. I also have Firefox containers for important things like banking - a phishing url from my email will not open in the correct container. Huge red flag.
- pjmlp 6y ago
  That is changing with Android 11, which will require hardware memory tagging on ARM based devices. Non-ARM devices will make use of a kernel fuzzer that chooses OS processes as victims to test. Also Google keeps reducing the areas you are supposed to reach out to the NDK anyway.
panpanna 6y ago
Looking the bottom part, is APRR the only mitigation exclusive to Apples own CPUs? Also, is trustzone not available on these?
- RL_Quine 6y ago
  There's no trustzone, no, but boot is completely verified in much stronger ways. Software updates are uniquely signed per device, per execution to prevent downgrade attacks.
  - q3k 6y ago
    TrustZone is orthogonal to secure boot. It's close to functionality to SGX, trying to allow for some SecureElement-like functionality on the main SoC (in which you can do crypto, DRM, etc).
    - panpanna 6y ago
      Just a tiny remark: I think trustzone is mostly used for drm these days, SE has its own dedicated security processor on Qualcomm and (iirc) Huawei socs
  - panpanna 6y ago
    This confused me. How does these unique signatures work and how does it improve boot security?
    - ghostpepper 6y ago
      IIRC the general idea is that the pin code or password is required to be entered when an update is requested, which unlocks a key pair. The public key is included in the update request, which is then sent to Apple. Apple sends back a download that is signed in a way that the firmware can verify, and Apple guarantees never to send another download in response to that exact request. This protection also relies on the secure enclave never authorizing the installation of an unsigned OS update.
cancerSpreads 6y ago
Bookmarked for anytime someone tells me Apple products are secure. Marketing doesn't line up with reality. Not that those who parrot the marketing would be convinced with evidence.
- zepto 6y ago
  It seems like marketing exactly lines up with reality. Security is relative, and compared to the alternatives, iOS is indeed secure.
- pjmlp 6y ago
  No need, the security updates list already provides plenty of CVEs examples caused by memory corruption issues.
  - deleted 6y ago
    [deleted]
- hn_check 6y ago
  No software is completely secure, and even the most junior developer operates under that assumption. Therefore everything is relative. Do you really think the Android list would be shorter, or less consequential?
- AnonC 6y ago
  Hope you also tell people who use Android about the dismal state of updates (actually the lack of it) from most manufacturers and how most new phones come with older versions with security vulnerabilities not patched on that device (and probably will never be patched).
- simonh 6y ago
  So according to this article those of us on iOS 13.x (93% of the installed base) used to have one vulnerability, which we got patched through auto-updates 8 months ago. I'm quaking in my boots. I hope you remember to point out the historical nature of this when you pass on the link.
AnonC 6y ago
Hoping to see such a list for Android too. I don’t see one right now. [1] Some kind of comparison between iOS and Android on the kinds of issues and underlying causes would also be interesting. [1]: https://duckduckgo.com/?q=site%3Agoogleprojectzero.blogspot.com+android+kernel https://duckduckgo.com/?q=site%3Agoogleprojectzero.blogspot....
- numbsafari 6y ago
  I really appreciate and enjoy the work done by Project Zero. But, it often does feel like it could be retitled Project Schadenfreude. This particular post almost feels timed specifically for release right before WWDC.
  - brian_herman__ 6y ago
    It agree wholeheartedly I was just going to post the same comment!
  - snazz 6y ago
    They're doing Apple a huge favor by discovering these bugs. They're doing the security community a huge favor by publishing blog posts about them for others to learn from. They also do plenty of Android research, although iOS is a higher priority since most security-conscious people use iOS (including the researchers themselves). This is not a hit piece on Apple.
    - zepto 6y ago
      I’m not sure how this argument makes sense. Most people use Android. I don’t see any evidence that supports the claim that most “security-conscious“ people use iOS. If it is somehow meaningful to make that claim, then it is all the more important for project zero to focus on Android, since people who are not security conscious are less likely to practice other forms of security. Project zero simply doesn’t seem to publish these pieces about Android at the same rate they do about iOS. Perhaps this is unintentional.
      - 6y ago
LucidLynx 6y ago
For people who think that there is far more CVE on iOS than Android (based on this article): https://www.cvedetails.com/top-50-products.php?year=2019 https://www.cvedetails.com/top-50-products.php?year=2019 And it's for 2019 only
- saagarjha 6y ago
  Number of CVEs in general is a fairly poor way to evaluate the security of a platform.
  - LucidLynx 6y ago
    Hum... In this sentence: "For people who think that there is far more CVE on iOS than Android", when did I speaked about evaluating a security of a platform based on CVE? When? I was only discussing about the fact that iOS does not have more CVE than Android, based on other discussions on this thread... I am sorry if this message is mean but... did you read my comment at least?
    - saagarjha 6y ago
      Just like nobody explicitly said that iOS has more CVEs?
      - LucidLynx 6y ago
        Read the comment just before please...
        saagarjha 6y ago
        No, I did, although I should apologize for the slightly snarky response. I think your original comment was a valuable one, as it did bring up an interesting point that Android sees more CVEs than iOS does. However, I think the point is even more fundamental: counting the number of bugs on a list is not a great way of showing a platform is secure/insecure, although many people may believe so, just like they may look at this list and think "gee, iOS is so full of bugs it must be worse than Android!" Really, the point of this blog post was just a compilation of methods that achieve arbitrary code execution in the kernel based on how they did so and which iOS versions they apply to, instead of being some sort of comparison between operating systems.
fortran77 6y ago
Amazing how something marketed as "secure by design" is, in fact, designed with the same issues as other competitive operating systems. https://www.apple.com/business/docs/site/AAW_Platform_Security.pdf https://www.apple.com/business/docs/site/AAW_Platform_Securi...
- saagarjha 6y ago
  Rather than responding to this again, I'll let the responses you got the other times you asked this do the talking: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=%22secure%20by%20design%22%20fortran77&sort=byPopularity&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

120 points by edmorley 6y ago

Great summary list near end of article of the various mitigations used by iOS - there is quite a few hardware protections implemented within the processors themselves. Android is less of a monoculture, but also has less opportunity to tune the processor to include strong hardware mitigations against whole classes of vulnerabilities.

stefan_ 6y ago
While iOS seems to pioneer every mitigation technique ever described in the literature, they also shipped ancient versions of C image parsing libs (OpenEXR), have an endless stream of remote code execution vulnerabilities from their peculiar serialization schemes and all the other issues you would expect from the use of native ObjC. Their commitment is squarely to mitigating issues that threaten the walled garden (and therefore the kernel), not so much userspace.
- RL_Quine 6y ago
  I don't think that's really fair, those classes of exploits (ie, libtiff / jailbreak.me) were around a decade ago now.
  - tsbinz 6y ago
    https://googleprojectzero.blogspot.com/2020/04/fuzzing-imageio.html https://googleprojectzero.blogspot.com/2020/04/fuzzing-image... isn't a decade old, on the contrary.
- pjmlp 6y ago
  Solaris on SPARC did hardware memory tagging much earlier than iOS.
  - saagarjha 6y ago
    iOS doesn’t actually do hardware memory tagging at all.
    - pjmlp 6y ago
      Yes it does after iPhone X, aka pointer validation in Apple speak.
      - saagarjha 6y ago
        Pointer authentication is not hardware memory tagging. (Also, PAC shipped with iPhone XS.)
        pjmlp 6y ago
        Playing word games when the actual technical outcome for preventing memory corruption is the same one.
        saagarjha 6y ago
        No, they are entirely different features. Pointer authentication is largely a control-flow integrity feature. Hardware memory tagging attempts to prevents arbitrary overwrites/memory corruption, even to data. There are dozens of other features that prevent memory corruption and it's not really "playing word games" to distinguish between them.
        pjmlp 6y ago
        It is still conceptually the same from my point of view, and the data structures used by the hardned runtime.
        saagarjha 6y ago
        I assume you're not talking about this: https://developer.apple.com/documentation/security/hardened_runtime https://developer.apple.com/documentation/security/hardened_...? And to your other point: the difference between these things do matter because they have entirely different semantics and protect against different things, although the overarching goal of preventing undesired operation is the same. Taking the metaphor one level up to apply to computer science rather than security, this is like saying that the borrow checker and asserts are both the same from a certain point of view because they both help prevent bugs. Which is true, of course, but when you're talking about a programming language's safety features saying something like "C can prevent use-after-free because of its borrow checker" is not correct nor can you make it relevant by saying something like "yeah but C has asserts and they also help prevent bugs so from my point of view I think you're being pedantic".
- amluto 6y ago
  The issue doesn’t seem to be ObjC per se. It’s the use of a facility that tries to transparently serialize an object in any rich language. Python pickle has the same issue, although it’s arguably worse in Python. The solution is to abandon the whole approach — these systems should not be used across trust boundaries. Apple should create iMessage v2 using a real serialization system (protobuf, JSON, XML, ASN.1, etc) and deprecate the old scheme. It’s surely possibly to write a safe but non-extensible deserializer for the old protocol if compatibility is needed.
- saagarjha 6y ago
  iOS also sometimes creates their own mitigation techniques. Sometimes these are quite strong but often they are…not really mitigating anything; in rare cases they make the situation worse. Shipping every mitigation under the sun is not necessary a good idea.
- dontbenebby 6y ago
  >Their commitment is squarely to mitigating issues that threaten the walled garden (and therefore the kernel), not so much userspace. As a practical matter, doesn't this mean if I'm confident in my ability to avoid phishing messages, iOS is better? Anything that "roots" a phone can also run roughshod, turn on my mic, grab signal messages stored locally, etc, correct? What I'm getting at is a phone in a walled garden + a laptop that's open source might be the best way to get the security of the walled garden and the utility of open source.
  - stefan_ 6y ago
    I'd argue it is the opposite. The people that want to grab your Signal or WhatsApp messages can often do so by simply sending your some picture or specially crafted message; it's only the people that want to run their own software that need to break all the kernel defenses and 'root' the device.
  - fomine3 6y ago
    "confident in my ability to avoid phishing messages" is not a good way for security.
    - dontbenebby 6y ago
      I literally designed antiphishing trainings. I also have Firefox containers for important things like banking - a phishing url from my email will not open in the correct container. Huge red flag.
pjmlp 6y ago
That is changing with Android 11, which will require hardware memory tagging on ARM based devices. Non-ARM devices will make use of a kernel fuzzer that chooses OS processes as victims to test. Also Google keeps reducing the areas you are supposed to reach out to the NDK anyway.

panpanna 6y ago

Looking the bottom part, is APRR the only mitigation exclusive to Apples own CPUs? Also, is trustzone not available on these?

RL_Quine 6y ago
There's no trustzone, no, but boot is completely verified in much stronger ways. Software updates are uniquely signed per device, per execution to prevent downgrade attacks.
- q3k 6y ago
  TrustZone is orthogonal to secure boot. It's close to functionality to SGX, trying to allow for some SecureElement-like functionality on the main SoC (in which you can do crypto, DRM, etc).
  - panpanna 6y ago
    Just a tiny remark: I think trustzone is mostly used for drm these days, SE has its own dedicated security processor on Qualcomm and (iirc) Huawei socs
- panpanna 6y ago
  This confused me. How does these unique signatures work and how does it improve boot security?
  - ghostpepper 6y ago
    IIRC the general idea is that the pin code or password is required to be entered when an update is requested, which unlocks a key pair. The public key is included in the update request, which is then sent to Apple. Apple sends back a download that is signed in a way that the firmware can verify, and Apple guarantees never to send another download in response to that exact request. This protection also relies on the secure enclave never authorizing the installation of an unsigned OS update.

cancerSpreads 6y ago

Bookmarked for anytime someone tells me Apple products are secure. Marketing doesn't line up with reality. Not that those who parrot the marketing would be convinced with evidence.

zepto 6y ago
It seems like marketing exactly lines up with reality. Security is relative, and compared to the alternatives, iOS is indeed secure.
pjmlp 6y ago
No need, the security updates list already provides plenty of CVEs examples caused by memory corruption issues.
- deleted 6y ago
  [deleted]
hn_check 6y ago
No software is completely secure, and even the most junior developer operates under that assumption. Therefore everything is relative. Do you really think the Android list would be shorter, or less consequential?
AnonC 6y ago
Hope you also tell people who use Android about the dismal state of updates (actually the lack of it) from most manufacturers and how most new phones come with older versions with security vulnerabilities not patched on that device (and probably will never be patched).
simonh 6y ago
So according to this article those of us on iOS 13.x (93% of the installed base) used to have one vulnerability, which we got patched through auto-updates 8 months ago. I'm quaking in my boots. I hope you remember to point out the historical nature of this when you pass on the link.

AnonC 6y ago

Hoping to see such a list for Android too. I don’t see one right now. [1] Some kind of comparison between iOS and Android on the kinds of issues and underlying causes would also be interesting. [1]: https://duckduckgo.com/?q=site%3Agoogleprojectzero.blogspot.com+android+kernel https://duckduckgo.com/?q=site%3Agoogleprojectzero.blogspot....

numbsafari 6y ago
I really appreciate and enjoy the work done by Project Zero. But, it often does feel like it could be retitled Project Schadenfreude. This particular post almost feels timed specifically for release right before WWDC.
- brian_herman__ 6y ago
  It agree wholeheartedly I was just going to post the same comment!
- snazz 6y ago
  They're doing Apple a huge favor by discovering these bugs. They're doing the security community a huge favor by publishing blog posts about them for others to learn from. They also do plenty of Android research, although iOS is a higher priority since most security-conscious people use iOS (including the researchers themselves). This is not a hit piece on Apple.
  - zepto 6y ago
    I’m not sure how this argument makes sense. Most people use Android. I don’t see any evidence that supports the claim that most “security-conscious“ people use iOS. If it is somehow meaningful to make that claim, then it is all the more important for project zero to focus on Android, since people who are not security conscious are less likely to practice other forms of security. Project zero simply doesn’t seem to publish these pieces about Android at the same rate they do about iOS. Perhaps this is unintentional.
    - 6y ago

LucidLynx 6y ago

For people who think that there is far more CVE on iOS than Android (based on this article): https://www.cvedetails.com/top-50-products.php?year=2019 https://www.cvedetails.com/top-50-products.php?year=2019 And it's for 2019 only

saagarjha 6y ago
Number of CVEs in general is a fairly poor way to evaluate the security of a platform.
- LucidLynx 6y ago
  Hum... In this sentence: "For people who think that there is far more CVE on iOS than Android", when did I speaked about evaluating a security of a platform based on CVE? When? I was only discussing about the fact that iOS does not have more CVE than Android, based on other discussions on this thread... I am sorry if this message is mean but... did you read my comment at least?
  - saagarjha 6y ago
    Just like nobody explicitly said that iOS has more CVEs?
    - LucidLynx 6y ago
      Read the comment just before please...
      - saagarjha 6y ago
        No, I did, although I should apologize for the slightly snarky response. I think your original comment was a valuable one, as it did bring up an interesting point that Android sees more CVEs than iOS does. However, I think the point is even more fundamental: counting the number of bugs on a list is not a great way of showing a platform is secure/insecure, although many people may believe so, just like they may look at this list and think "gee, iOS is so full of bugs it must be worse than Android!" Really, the point of this blog post was just a compilation of methods that achieve arbitrary code execution in the kernel based on how they did so and which iOS versions they apply to, instead of being some sort of comparison between operating systems.

fortran77 6y ago

Amazing how something marketed as "secure by design" is, in fact, designed with the same issues as other competitive operating systems. https://www.apple.com/business/docs/site/AAW_Platform_Security.pdf https://www.apple.com/business/docs/site/AAW_Platform_Securi...

saagarjha 6y ago
Rather than responding to this again, I'll let the responses you got the other times you asked this do the talking: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=%22secure%20by%20design%22%20fortran77&sort=byPopularity&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...