8 ms·

The Many Possibilities of iMessage File Vulnerability

279 points by jakejarvis 7y ago

doctorpangloss 7y ago
Pretty wild! Serialization bugs are the worst, since receiving weird, untrusted data happens all the time. People think this is about Java and class names and stuff, but it's really about receiving multimedia and decoding it in a performant way. When will people discover all the vulnerabilities in video codecs, fonts and shaders?
- java-man 7y ago
  I am afraid never - security is never a design goal, even when security is the main purpose of the software (OpenSSL/ heartbleed).
  - miloignis 7y ago
    That's why I think formally verified implementations are so critical, and why Project Everest (formally verified TLS) is so cool: https://project-everest.github.io/ https://project-everest.github.io/
    - johnisgood 7y ago
      Also: https://github.com/Componolit/libsparkcrypto https://github.com/Componolit/libsparkcrypto
      - java-man 7y ago
        Not an ADA guy, just curious: 1. does this library provide a way to clear secrets from memory? 2. does it provide means to ensure that the secrets will not be swapped to disk on page fault or copied in memory? 3. does it bignum implementation provide a way to clear the internal buffer? thank you.
        johnisgood 7y ago
        Hey! I only found https://github.com/Componolit/libsparkcrypto/blob/0a3a3c5ed74f483e5d8539e2d84bf988547bf5b4/src/shared/generic/lsc-internal-pad64.adb https://github.com/Componolit/libsparkcrypto/blob/0a3a3c5ed7.... I hope someone who is more acquainted will help us out. In any case, you should read: - https://www.auto.tuwien.ac.at/~blieb/AE2017/presentations/ae2017_chapman.pdf https://www.auto.tuwien.ac.at/~blieb/AE2017/presentations/ae... - https://www.auto.tuwien.ac.at/~blieb/AE2017/presentations/Hardware-based-data-protection-in-Ada.pdf https://www.auto.tuwien.ac.at/~blieb/AE2017/presentations/Ha... - https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/protect-secrets.html https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/p... - https://dwheeler.com/lovelace/s17s5.htm https://dwheeler.com/lovelace/s17s5.htm
- cjbprime 7y ago
  Thankfully, file formats are actually one of the more tractable places to find bugs these days, thanks to the rise of fuzzers running on extreme levels of compute resources.
- ljackman 7y ago
  Agreed. A lot of serialisation support in mainstream languages seem to stand in stark contrast to the principles of langsec [1]. This bug reminded me a bit of Heartbleed actually; it’s pretty different but has that one similarity of two payload lengths, one reported and one actual, disagreeing and not being reconciled, causing memory bugs. Even with memory safe languages, when you go beyond basic serialisation and look at libraries like Jackson for Java, you discover _very_ questionable designs such as providing an API that makes it all too convenient to switch on a feature which allows user-provided strings to control which classes to instantiate. They solve this using a blacklist of “known bad classes”, which seems to be a workaround rather than acknowledging that many features of common serialisation libraries are a fully loaded uzi pointing at the developer’s foot. It seems common implementations of serialisation and deserialisation have prioritised ease of use for the developer over declaring clear, bounded intent, and this seems to apply from ad hoc C parsing of network payloads all the way up to automatic serialisation in memory-safe languages. [1] http://langsec.org/ http://langsec.org/
- deleted 7y ago
  [deleted]
- kevingadd 7y ago
  Lots of project zero's previous work has been focused on fonts and video codecs (along with realtime voice/video chat). It's worth reviewing their blog, they published some stuff on facetime recently.
olliej 7y ago
The core problem is deserialization formats where the serialized content specifies that class that should be instantiated. See the yaml, pickle, Java, etc serialization bugs over the years. The real kicker here is that someone was clearly trying to do the correct thing (see mentions of secure coding), but the way secure coding works meant that arbitrary subclasses of any type that declared itself as supporting secure coding could be instantiated. Because the subclasses don't necessarily actually support secure coding you get much sadness. There are things that could be done to make deserialization safer, but the core problem will remain that the untrusted content gets to specify the classes that will be instantiated.
- saagarjha 7y ago
  I think the specific issue was that subclasses didn't support the semantics of the classes they inherited from correctly.
  - olliej 7y ago
    Yes, but the reason for that is because the subclasses didn't recognize that they were expected to conform to secure coding. Because subclasses inherit the value of the class flag supportsSecureCoding without any obvious indication of that. The problem is that the core design of NSCodable (and NSSEcureCoding) is that the serialized data get to specify the type to instantiate, and the way supportsSecureCoding is exposed means that the claim to secure coding is inherited. The former is a fairly common problem in serialization systems, and the security flaws in that approach resulted in the subsequent NSSecureCoding APIs. The latter is a byproduct of how secure coding is implemented, and it results in any user of NSSecureCoding needing to be aware of all classes that may be transitively pulled into their address space. The subclassing semantics means that even the explicit list of allowed classes is not sufficiently robust - e.g '@interface ArbitraryInsecureClass : NSData' means ArbitraryInsecureClass can be instantiated if you allow NSData in the secure coding list, and ArbitraryInsecureClass could be declared in some transitively included framework, and is generally leaked implementation details. These are all "fixable" for some value of fixable constrained by binary compatibility (though some of it could be mitigated by Darwin's linked-on-or-after mechanisms). There are a variety of steps that Apple could take that would make the entire NSCoding mechanism much more safe/secure without (afaict) necessarily breaking anything, though obviously I don't have access to the compatibility information they probably have. Things I would do (if I were king?): * Compiler warning when you subclass a class that declared supportsSecureCoding * Make the allowed classes restrict to explicit classes rather than just conforming classes (e.g. if you say NSData you can't instantiate a subclass of NSData) - I would give good odds of this breaking things * Rather than just checking the value of TargetClass.supportsSecureCoding I'd query the runtime to require supportsSecureCoding being a direct class member of TargetClass * I would consider adding a "+property secureClass: Class" (or whatever the syntax is) that is instantiated, so even if you aren't using secure coding you end up instantiating a sane type - though it would be "optional" due to existing code and objects not having the property. But then at least Apple could go through the core types in Foundation (Array, Data, String, etc) and make it so you would only ever instantiate understood classes. This would make the API slightly less footgun heavy.
ljackman 7y ago
I’m glad we’re seeing so many security vulnerabilities being exposed in the lower-level parts of the consumer OSes whose security we all take for granted. Doing writeups of compromised webapps is also great of course, but selling the importance of security to laypeople is easier as “the root of trust of your digital life was compromised in a certain way” than “a webapp for that service that only 2% of your country uses was compromised, so be sure to reset your passwords if you’re one of the unlucky ones”. Non-techies take a lot of the core infrastructure and tooling for granted, not realising just what a heap of technical debt and accrued complexity it all is, and therefore just how hard it is to keep secure, despite the large security budgets and talents of the big FAANG companies. It’s only by these lower levels being attacked and yielding bad PR for their parent companies will we eventually see less of a focus on new features for core ecosystem platforms and more of a focus on reducing the technical complexity and improving the security of what we have. This will however need to be combined with technology journalism that’s more focussed on putting such vulnerabilities into accessible stories for the layperson and less focussed on being the unofficial marketing wing of technology companies on announcements.
saagarjha 7y ago
> For a non-mutable string, it sometimes just increases the retain count on the string, but that also shouldn’t be a problem, because the contents of a mutable string can’t change. Perhaps this should have been "the contents of an immutable string can't change" ;)
Someone1234 7y ago
To me the key question is: Why is iMessage not a normal iOS app? We've seen numerous iMessage bugs over the years inc. full OS take-overs (often used for jailbreak), soft bricking (endless restarts due to corrupt notifications/requiring a factory reset), crashes that reboot the phone (once), and a bunch of potential for escalation/code execution. None of this is possible with apps in the normal iOS sandbox. The apps themselves would crash, but they're context confined, they cannot bring down the underlying OS, write invalid notifications, or cause a kernel panic. But they've designed iMessage to act like a part of the underlying OS for no real reason. You could very easily hand off the most hazardous parts of iMessage's inner workings into the app's context, or even another user space/context confined service, and just let them crash like normal apps do. Ten years ago it was common for font processing to happen in the kernel. This was problematic because front processing is hard, and bugs occur. Since then we've seen many migrate fonts into userland. Why is iMessage's security model so far behind the times, it is a lot less critical/performance impacted than fonts, but yet has worse security than most font systems in 2019?
- colejohnson66 7y ago
  Maybe because they want to integrate it with the Messages app so it’s used without having to worry about it? Could they still keep it integrated and put it in userland?
- csande17 7y ago
  I suspect it's because historically, iOS didn't have a way to embed views from one app into another app. When Apple wanted to let you view iMessages from the lock screen, or expose iMessage via Share buttons in third-party apps, they accomplished that by shoving most of iMessage into the operating system itself. These days, there are systems to do this properly (it's how third-party keyboards work, for example), but Apple is a small indie company that does not have the resources to refactor iMessage to use the iOS features they created.
  - ksahin 7y ago
    > These days, there are systems to do this properly (it's how third-party keyboards work, for example), but Apple is a small indie company that does not have the resources to refactor iMessage to use the iOS features they created. You made my day thanks !
samstave 7y ago
Is there any guestimation on nust the sheer volume of data sent each day wit iMessage (blue messages, not green sms ones)
- saagarjha 7y ago
  This number way about 40 billion in 2014: https://www.macrumors.com/2014/02/28/apple-40-billion-imessages/ https://www.macrumors.com/2014/02/28/apple-40-billion-imessa...
  - samstave 7y ago
    If my calculations are correct; A typical sms is 140 bytes... At 40B messages Thats 57 terabytes a day But imessage isnt limited to 160 characters So lets double that. And about 100 TB a day as of 2014 - so lets triple that. And assume 300 TB per day in messaging And lets divide that in two for between iMessage and sms But since android tops ios in global qty of devices.. Lets double it. And where in the past the Philippines was known to be the top users of sms, but with ayala scaling up over the last years... lets quadruple that number and so i would estimate 600 TB a day in just iMessage and sms alone.
    - saagarjha 7y ago
      iMessage does file transfer too!
      - samstave 7y ago
        Yeah id say its likely closer to a PB a day globally.
    - airstrike 7y ago
      I love this. Reminded me of one time some 15+ years ago I did some back-of-the-envelope math like yours but on people using colored characters on every message on IRC w/ scripts and how much meaningless data that generated... it's astonishing how quickly you can get to the PB scale
Sniffnoy 7y ago
Non-mobile link: https://googleprojectzero.blogspot.com/2019/08/the-many-possibilities-of-cve-2019-8646.html https://googleprojectzero.blogspot.com/2019/08/the-many-poss...
auslander 7y ago
"The process we follow to increase security is simply a comprehensive file-by-file analysis of every critical software component. We are not so much looking for security holes, as we are looking for basic software bugs, and if years later someone discovers the problem used to be a security issue, and we fixed it because it was just a bug, well, all the better. " https://www.openbsd.org/security.html https://www.openbsd.org/security.html
panpanna 7y ago
Possibly dumb question: If this was submitted to apples $1M bounty program, would it qualify for the whole amount?
- saagarjha 7y ago
  I can’t see this getting more than $500,000.

279 points by jakejarvis 7y ago

Pretty wild! Serialization bugs are the worst, since receiving weird, untrusted data happens all the time. People think this is about Java and class names and stuff, but it's really about receiving multimedia and decoding it in a performant way. When will people discover all the vulnerabilities in video codecs, fonts and shaders?

java-man 7y ago
I am afraid never - security is never a design goal, even when security is the main purpose of the software (OpenSSL/ heartbleed).
- miloignis 7y ago
  That's why I think formally verified implementations are so critical, and why Project Everest (formally verified TLS) is so cool: https://project-everest.github.io/ https://project-everest.github.io/
  - johnisgood 7y ago
    Also: https://github.com/Componolit/libsparkcrypto https://github.com/Componolit/libsparkcrypto
    - java-man 7y ago
      Not an ADA guy, just curious: 1. does this library provide a way to clear secrets from memory? 2. does it provide means to ensure that the secrets will not be swapped to disk on page fault or copied in memory? 3. does it bignum implementation provide a way to clear the internal buffer? thank you.
      - johnisgood 7y ago
        Hey! I only found https://github.com/Componolit/libsparkcrypto/blob/0a3a3c5ed74f483e5d8539e2d84bf988547bf5b4/src/shared/generic/lsc-internal-pad64.adb https://github.com/Componolit/libsparkcrypto/blob/0a3a3c5ed7.... I hope someone who is more acquainted will help us out. In any case, you should read: - https://www.auto.tuwien.ac.at/~blieb/AE2017/presentations/ae2017_chapman.pdf https://www.auto.tuwien.ac.at/~blieb/AE2017/presentations/ae... - https://www.auto.tuwien.ac.at/~blieb/AE2017/presentations/Hardware-based-data-protection-in-Ada.pdf https://www.auto.tuwien.ac.at/~blieb/AE2017/presentations/Ha... - https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/protect-secrets.html https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/p... - https://dwheeler.com/lovelace/s17s5.htm https://dwheeler.com/lovelace/s17s5.htm
cjbprime 7y ago
Thankfully, file formats are actually one of the more tractable places to find bugs these days, thanks to the rise of fuzzers running on extreme levels of compute resources.
ljackman 7y ago
Agreed. A lot of serialisation support in mainstream languages seem to stand in stark contrast to the principles of langsec [1]. This bug reminded me a bit of Heartbleed actually; it’s pretty different but has that one similarity of two payload lengths, one reported and one actual, disagreeing and not being reconciled, causing memory bugs. Even with memory safe languages, when you go beyond basic serialisation and look at libraries like Jackson for Java, you discover _very_ questionable designs such as providing an API that makes it all too convenient to switch on a feature which allows user-provided strings to control which classes to instantiate. They solve this using a blacklist of “known bad classes”, which seems to be a workaround rather than acknowledging that many features of common serialisation libraries are a fully loaded uzi pointing at the developer’s foot. It seems common implementations of serialisation and deserialisation have prioritised ease of use for the developer over declaring clear, bounded intent, and this seems to apply from ad hoc C parsing of network payloads all the way up to automatic serialisation in memory-safe languages. [1] http://langsec.org/ http://langsec.org/
deleted 7y ago
[deleted]
kevingadd 7y ago
Lots of project zero's previous work has been focused on fonts and video codecs (along with realtime voice/video chat). It's worth reviewing their blog, they published some stuff on facetime recently.

olliej 7y ago

The core problem is deserialization formats where the serialized content specifies that class that should be instantiated. See the yaml, pickle, Java, etc serialization bugs over the years. The real kicker here is that someone was clearly trying to do the correct thing (see mentions of secure coding), but the way secure coding works meant that arbitrary subclasses of any type that declared itself as supporting secure coding could be instantiated. Because the subclasses don't necessarily actually support secure coding you get much sadness. There are things that could be done to make deserialization safer, but the core problem will remain that the untrusted content gets to specify the classes that will be instantiated.

saagarjha 7y ago
I think the specific issue was that subclasses didn't support the semantics of the classes they inherited from correctly.
- olliej 7y ago
  Yes, but the reason for that is because the subclasses didn't recognize that they were expected to conform to secure coding. Because subclasses inherit the value of the class flag supportsSecureCoding without any obvious indication of that. The problem is that the core design of NSCodable (and NSSEcureCoding) is that the serialized data get to specify the type to instantiate, and the way supportsSecureCoding is exposed means that the claim to secure coding is inherited. The former is a fairly common problem in serialization systems, and the security flaws in that approach resulted in the subsequent NSSecureCoding APIs. The latter is a byproduct of how secure coding is implemented, and it results in any user of NSSecureCoding needing to be aware of all classes that may be transitively pulled into their address space. The subclassing semantics means that even the explicit list of allowed classes is not sufficiently robust - e.g '@interface ArbitraryInsecureClass : NSData' means ArbitraryInsecureClass can be instantiated if you allow NSData in the secure coding list, and ArbitraryInsecureClass could be declared in some transitively included framework, and is generally leaked implementation details. These are all "fixable" for some value of fixable constrained by binary compatibility (though some of it could be mitigated by Darwin's linked-on-or-after mechanisms). There are a variety of steps that Apple could take that would make the entire NSCoding mechanism much more safe/secure without (afaict) necessarily breaking anything, though obviously I don't have access to the compatibility information they probably have. Things I would do (if I were king?): * Compiler warning when you subclass a class that declared supportsSecureCoding * Make the allowed classes restrict to explicit classes rather than just conforming classes (e.g. if you say NSData you can't instantiate a subclass of NSData) - I would give good odds of this breaking things * Rather than just checking the value of TargetClass.supportsSecureCoding I'd query the runtime to require supportsSecureCoding being a direct class member of TargetClass * I would consider adding a "+property secureClass: Class" (or whatever the syntax is) that is instantiated, so even if you aren't using secure coding you end up instantiating a sane type - though it would be "optional" due to existing code and objects not having the property. But then at least Apple could go through the core types in Foundation (Array, Data, String, etc) and make it so you would only ever instantiate understood classes. This would make the API slightly less footgun heavy.

ljackman 7y ago

I’m glad we’re seeing so many security vulnerabilities being exposed in the lower-level parts of the consumer OSes whose security we all take for granted. Doing writeups of compromised webapps is also great of course, but selling the importance of security to laypeople is easier as “the root of trust of your digital life was compromised in a certain way” than “a webapp for that service that only 2% of your country uses was compromised, so be sure to reset your passwords if you’re one of the unlucky ones”. Non-techies take a lot of the core infrastructure and tooling for granted, not realising just what a heap of technical debt and accrued complexity it all is, and therefore just how hard it is to keep secure, despite the large security budgets and talents of the big FAANG companies. It’s only by these lower levels being attacked and yielding bad PR for their parent companies will we eventually see less of a focus on new features for core ecosystem platforms and more of a focus on reducing the technical complexity and improving the security of what we have. This will however need to be combined with technology journalism that’s more focussed on putting such vulnerabilities into accessible stories for the layperson and less focussed on being the unofficial marketing wing of technology companies on announcements.

saagarjha 7y ago

> For a non-mutable string, it sometimes just increases the retain count on the string, but that also shouldn’t be a problem, because the contents of a mutable string can’t change. Perhaps this should have been "the contents of an immutable string can't change" ;)

Someone1234 7y ago

To me the key question is: Why is iMessage not a normal iOS app? We've seen numerous iMessage bugs over the years inc. full OS take-overs (often used for jailbreak), soft bricking (endless restarts due to corrupt notifications/requiring a factory reset), crashes that reboot the phone (once), and a bunch of potential for escalation/code execution. None of this is possible with apps in the normal iOS sandbox. The apps themselves would crash, but they're context confined, they cannot bring down the underlying OS, write invalid notifications, or cause a kernel panic. But they've designed iMessage to act like a part of the underlying OS for no real reason. You could very easily hand off the most hazardous parts of iMessage's inner workings into the app's context, or even another user space/context confined service, and just let them crash like normal apps do. Ten years ago it was common for font processing to happen in the kernel. This was problematic because front processing is hard, and bugs occur. Since then we've seen many migrate fonts into userland. Why is iMessage's security model so far behind the times, it is a lot less critical/performance impacted than fonts, but yet has worse security than most font systems in 2019?

colejohnson66 7y ago
Maybe because they want to integrate it with the Messages app so it’s used without having to worry about it? Could they still keep it integrated and put it in userland?
csande17 7y ago
I suspect it's because historically, iOS didn't have a way to embed views from one app into another app. When Apple wanted to let you view iMessages from the lock screen, or expose iMessage via Share buttons in third-party apps, they accomplished that by shoving most of iMessage into the operating system itself. These days, there are systems to do this properly (it's how third-party keyboards work, for example), but Apple is a small indie company that does not have the resources to refactor iMessage to use the iOS features they created.
- ksahin 7y ago
  > These days, there are systems to do this properly (it's how third-party keyboards work, for example), but Apple is a small indie company that does not have the resources to refactor iMessage to use the iOS features they created. You made my day thanks !

samstave 7y ago

Is there any guestimation on nust the sheer volume of data sent each day wit iMessage (blue messages, not green sms ones)

saagarjha 7y ago
This number way about 40 billion in 2014: https://www.macrumors.com/2014/02/28/apple-40-billion-imessages/ https://www.macrumors.com/2014/02/28/apple-40-billion-imessa...
- samstave 7y ago
  If my calculations are correct; A typical sms is 140 bytes... At 40B messages Thats 57 terabytes a day But imessage isnt limited to 160 characters So lets double that. And about 100 TB a day as of 2014 - so lets triple that. And assume 300 TB per day in messaging And lets divide that in two for between iMessage and sms But since android tops ios in global qty of devices.. Lets double it. And where in the past the Philippines was known to be the top users of sms, but with ayala scaling up over the last years... lets quadruple that number and so i would estimate 600 TB a day in just iMessage and sms alone.
  - saagarjha 7y ago
    iMessage does file transfer too!
    - samstave 7y ago
      Yeah id say its likely closer to a PB a day globally.
  - airstrike 7y ago
    I love this. Reminded me of one time some 15+ years ago I did some back-of-the-envelope math like yours but on people using colored characters on every message on IRC w/ scripts and how much meaningless data that generated... it's astonishing how quickly you can get to the PB scale

Sniffnoy 7y ago

Non-mobile link: https://googleprojectzero.blogspot.com/2019/08/the-many-possibilities-of-cve-2019-8646.html https://googleprojectzero.blogspot.com/2019/08/the-many-poss...

auslander 7y ago

"The process we follow to increase security is simply a comprehensive file-by-file analysis of every critical software component. We are not so much looking for security holes, as we are looking for basic software bugs, and if years later someone discovers the problem used to be a security issue, and we fixed it because it was just a bug, well, all the better. " https://www.openbsd.org/security.html https://www.openbsd.org/security.html

panpanna 7y ago

Possibly dumb question: If this was submitted to apples $1M bounty program, would it qualify for the whole amount?

saagarjha 7y ago
I can’t see this getting more than $500,000.