5 ms·

On the server, we have firecracker and gvisor to provide and extra layer of defense by not allowing userspace to directly access the kernel. Will that be the f

On the server, we have firecracker and gvisor to provide and extra layer of defense by not allowing userspace to directly access the kernel. Will that be the future on client devices as well given kernels are just too complex to secure perfectly?

arkadiyt 5y ago
As the tweet author notes, starting with iOS 14 Apple has moved iMessage parsing into a sandboxed "blastdoor" process - I'm surprised it was ineffective in stopping this exploit chain.
- tester756 5y ago
  Why there's so much parsing related exploits?
  - amelius 5y ago
    My guess: because most parsing uses the stack a lot, and the parsed language often allows arbitrary length inputs, both of which are connected to overflow problems, which in turn can often be exploited.
    - pojhvc 5y ago
      It's more often use-after-free or heap buffer overrun bugs, these days.
  - wyager 5y ago
    Because people implement parsers in languages that don’t allow direct expression of grammars (e.g. C). To safely implement parsers you must choose either algebraic datatypes or continuation passing, and a lot of programmers choose neither. CPS is annoying in most languages. ADTs are the obvious choice but somehow in 2021 most people are using languages that don’t have them. If you write a parser in Haskell, for example, you’d have to mess up pretty badly and write totally non-idiomatic code to write a parser that crashes at all, let alone crashes in a way that compromises memory safety.
    - tester756 5y ago
      >ADTs are the obvious choice but somehow in 2021 most people are using languages that don’t have them. Isn't inheritance to create hierarchy enough? why? Node SubNode1 SubNode2 SubNode1.1 SubNode2.1
      - wyager 5y ago
        Using inheritance in this way is a hack to emulate some of the functionality of ADTs. Grammars are perhaps one of the most poignant examples where the various constructors in your type might have no behaviors in common, so adherence to a shared interface is nothing but a vague indication that these types are somehow related. Sealed classes let you recover a little bit more of the functionality.
        tester756 5y ago
        well, but from security standpoint it should be fine?
    - roca 5y ago
      You can just use a handwritten parser in any memory-safe language. However, I suspect parsers for big objects like images tend to have more vulnerabilities because developers try to avoid copying data, for performance reasons. Many memory-safe languages have their own performance issues, or make it hard to avoid copying bulk data, so those languages aren't a great fit. This makes Rust a particularly good choice for writing parsers: Rust is pretty strong at supporting complex data sharing patterns while remaining memory-safe.
      - andrewmd5 5y ago
        If your goal is validation (i.e. this is a JPG/PNG) and stripping of EXIF data it is entirely possible to write your own parser in a managed and safe language in less than 500 lines of code without sacrificing any performance. Don’t load them into memory, parse them as a stream byte-by-byte in accordance with the standard for the codec, check every offset before seeking, and reject images that don’t conform to the standard. And of course, a ton of fuzzing to accompany it.
  - remus 5y ago
    > Why there's so much parsing related exploits? Broadly, because by necessity you're dealing with untrusted inputs in a relatively complex format. The complexity leaves room for bugs in how you handle the input and the user supplied data provides an easy way to feed malicious inputs in.
  - KaiserPro 5y ago
    Because writing a good parser that is fast, secure and works on a whole bunch of crappy/broken/non compliant formats is very hard. Sure its easy to write a fast, standards compliant parser (assuming its not a format like .psd or a word document), but it will choke on the multitude of dodgy versions of files out there, causing complaints _most_ users only care about the picture/sound/video/other viewing correctly, with security a distant second. (they expect it to be secure) so pressure is on to make the parse work with everything.
    - tlavoie 5y ago
      I get where product people will noisily demand this, but perhaps the idea of parsing even broken files successfully is a large part of the problem. HTML started this way, and it's still terrible. At an ancient job, we did a lot of scraping content from HTML as the de facto input source. Each content provider had to have custom code written, and it was as bad as you would expect. XML came about, and its largest advantage was that invalid input was broken, and must be rejected as such.
  - dsign 5y ago
    Are these parsing exploits connected to JPEGs? I don't know for sure, but I can understand how this could be a can of worms. The JPEG core format is complicated, but JPEGs in circulation today are simply nightmarish. They can include XMP, EXIF, and ICC data, plus a good dozen of other extensions that may actually affect how the JPEG is displayed. For example, knowing if a JPEG contains CMYK data depends on an Adobe extension with is about twenty years old. These extensions are in use today in images published in the web. So, just to display an image, one needs a parser for the image format, a parser for ICC, a parser for XMP, a parser for that obscure Adobe extension from twenty years ago, and so on. Often, each of them has its own library and represents decades of developer time. It's a lot of space for bugs and exploits.
  - quenix 5y ago
    My thinking is this: 1. Exploitation inherently relies on malicious input data. 2. In computer systems, any input data (especially in human-facing systems) is not logically useful to the software until parsed. 3. Thus, a parser is the first software element which systematically interacts with the input data. It is the prime exploitation target. That, + parsing complex data is just kind of hard to get right. If iMessage was UTF-8 only, this would not be an issue I'm sure.
deleted 5y ago
[deleted]
SheinhardtWigCo 5y ago
The future is memory safety, but to get there, they would need to rewrite and audit millions of lines of code. Targeted attacks against VIP users don't cause significant PR damage, so why go to all that effort?
- peteretep 5y ago
  > Targeted attacks against VIP users don't cause significant PR damage, so why go to all that effort? Because VIP users include people who run big-tech. Ask Bezos if it's worth fixing bugs that only target VIPs.
- tartoran 5y ago
  Id argue that exactly VIP users attacks cause a lot more significant PR damage and there is a more serious discussion and harsher criticism when an important person is involved somehow.
tomjen3 5y ago
The iPhone doesn't have to support anything other than the hardware it was born with, right? That should make for a much, much smaller and much simpler kernel.
- saagarjha 5y ago
  XNU is a fairly versatile kernel, it's not really possible (nor would it be particularly useful) to rip out everything that is not iPhone-specific.

arkadiyt 5y ago

As the tweet author notes, starting with iOS 14 Apple has moved iMessage parsing into a sandboxed "blastdoor" process - I'm surprised it was ineffective in stopping this exploit chain.

tester756 5y ago
Why there's so much parsing related exploits?
- amelius 5y ago
  My guess: because most parsing uses the stack a lot, and the parsed language often allows arbitrary length inputs, both of which are connected to overflow problems, which in turn can often be exploited.
  - pojhvc 5y ago
    It's more often use-after-free or heap buffer overrun bugs, these days.
- wyager 5y ago
  Because people implement parsers in languages that don’t allow direct expression of grammars (e.g. C). To safely implement parsers you must choose either algebraic datatypes or continuation passing, and a lot of programmers choose neither. CPS is annoying in most languages. ADTs are the obvious choice but somehow in 2021 most people are using languages that don’t have them. If you write a parser in Haskell, for example, you’d have to mess up pretty badly and write totally non-idiomatic code to write a parser that crashes at all, let alone crashes in a way that compromises memory safety.
  - tester756 5y ago
    >ADTs are the obvious choice but somehow in 2021 most people are using languages that don’t have them. Isn't inheritance to create hierarchy enough? why? Node SubNode1 SubNode2 SubNode1.1 SubNode2.1
    - wyager 5y ago
      Using inheritance in this way is a hack to emulate some of the functionality of ADTs. Grammars are perhaps one of the most poignant examples where the various constructors in your type might have no behaviors in common, so adherence to a shared interface is nothing but a vague indication that these types are somehow related. Sealed classes let you recover a little bit more of the functionality.
      - tester756 5y ago
        well, but from security standpoint it should be fine?
  - roca 5y ago
    You can just use a handwritten parser in any memory-safe language. However, I suspect parsers for big objects like images tend to have more vulnerabilities because developers try to avoid copying data, for performance reasons. Many memory-safe languages have their own performance issues, or make it hard to avoid copying bulk data, so those languages aren't a great fit. This makes Rust a particularly good choice for writing parsers: Rust is pretty strong at supporting complex data sharing patterns while remaining memory-safe.
    - andrewmd5 5y ago
      If your goal is validation (i.e. this is a JPG/PNG) and stripping of EXIF data it is entirely possible to write your own parser in a managed and safe language in less than 500 lines of code without sacrificing any performance. Don’t load them into memory, parse them as a stream byte-by-byte in accordance with the standard for the codec, check every offset before seeking, and reject images that don’t conform to the standard. And of course, a ton of fuzzing to accompany it.
- remus 5y ago
  > Why there's so much parsing related exploits? Broadly, because by necessity you're dealing with untrusted inputs in a relatively complex format. The complexity leaves room for bugs in how you handle the input and the user supplied data provides an easy way to feed malicious inputs in.
- KaiserPro 5y ago
  Because writing a good parser that is fast, secure and works on a whole bunch of crappy/broken/non compliant formats is very hard. Sure its easy to write a fast, standards compliant parser (assuming its not a format like .psd or a word document), but it will choke on the multitude of dodgy versions of files out there, causing complaints _most_ users only care about the picture/sound/video/other viewing correctly, with security a distant second. (they expect it to be secure) so pressure is on to make the parse work with everything.
  - tlavoie 5y ago
    I get where product people will noisily demand this, but perhaps the idea of parsing even broken files successfully is a large part of the problem. HTML started this way, and it's still terrible. At an ancient job, we did a lot of scraping content from HTML as the de facto input source. Each content provider had to have custom code written, and it was as bad as you would expect. XML came about, and its largest advantage was that invalid input was broken, and must be rejected as such.
- dsign 5y ago
  Are these parsing exploits connected to JPEGs? I don't know for sure, but I can understand how this could be a can of worms. The JPEG core format is complicated, but JPEGs in circulation today are simply nightmarish. They can include XMP, EXIF, and ICC data, plus a good dozen of other extensions that may actually affect how the JPEG is displayed. For example, knowing if a JPEG contains CMYK data depends on an Adobe extension with is about twenty years old. These extensions are in use today in images published in the web. So, just to display an image, one needs a parser for the image format, a parser for ICC, a parser for XMP, a parser for that obscure Adobe extension from twenty years ago, and so on. Often, each of them has its own library and represents decades of developer time. It's a lot of space for bugs and exploits.
- quenix 5y ago
  My thinking is this: 1. Exploitation inherently relies on malicious input data. 2. In computer systems, any input data (especially in human-facing systems) is not logically useful to the software until parsed. 3. Thus, a parser is the first software element which systematically interacts with the input data. It is the prime exploitation target. That, + parsing complex data is just kind of hard to get right. If iMessage was UTF-8 only, this would not be an issue I'm sure.

deleted 5y ago

[deleted]

SheinhardtWigCo 5y ago

The future is memory safety, but to get there, they would need to rewrite and audit millions of lines of code. Targeted attacks against VIP users don't cause significant PR damage, so why go to all that effort?

peteretep 5y ago
> Targeted attacks against VIP users don't cause significant PR damage, so why go to all that effort? Because VIP users include people who run big-tech. Ask Bezos if it's worth fixing bugs that only target VIPs.
tartoran 5y ago
Id argue that exactly VIP users attacks cause a lot more significant PR damage and there is a more serious discussion and harsher criticism when an important person is involved somehow.

tomjen3 5y ago

The iPhone doesn't have to support anything other than the hardware it was born with, right? That should make for a much, much smaller and much simpler kernel.

saagarjha 5y ago
XNU is a fairly versatile kernel, it's not really possible (nor would it be particularly useful) to rip out everything that is not iPhone-specific.