9 ms·

If you show me software that's immune to advanced 0-days, I'll show you software that isn't usable.

ketralnis 3y ago
That's needlessly defeatist and "it's so bad out there there's no point in trying" is a thought terminating cliché. We can and should improve development practises, mitigate vulnerabities (ASLR, WAFs, etc), isolate systems from each other, and model threats in a way that we know where and how to do those things. It's not easy but just moaning "everything sucks" isn't how to fix it.
- otterley 3y ago
  Apple, Google, etc. have whole teams of talented people dedicated to doing exactly these types of things, and they undoubtedly help prevent many vulnerabilities from escaping the labs. Yet vulnerabilities are still created and exploited despite their best efforts. As long as software is created by imperfect humans, it will reflect the imperfections of its creators.
  - mensetmanusman 3y ago
    Not only humans, the math says it’s not knowable whether any open ended hardware/software is inherently safe.
    - sudosysgen 3y ago
      It's not knowable for any, but it is knowable for some. You just have to build systems that are in the some and are inherently safe. Difficult, not impossible.
      - PradeetPatel 3y ago
        Difficult often implies additional resourcing and development related costs. Something that many companies are not willing to invest in since it will have a negative impact on the shareholder values. Often risks are accepted, and cybersecurity insurance is used to mitigate those risks.
        sudosysgen 3y ago
        I agree, I just wanted to clarify that isn't mathematically impossible to make provably secure systems. It's just hard enough that it's not often done.
  - 2OEH8eoCRo0 3y ago
    This is my take as well. If Apple and Google can't do it then what hope does anyone else have? The current paradigm is insecure and broken.
- kaba0 3y ago
  As sibling commenter wrote: they do exactly that. But the same way we fail to see all the cases prevented by vaccines, you only see when their work fail to work in the rare case.
hot_gril 3y ago
Or just slow. If you don't care about optimization and run things in really inefficient sandboxes, security becomes a lot easier.
- Dylan16807 3y ago
  How fast does iMessage image decoding need to be? And I mean this extremely rhetorically. The software launched along with the iPhone 4S. Going by geekbench, that CPU was 20-30 times weaker than a modern iPhone on a per-core basis. I know the screens on the new phones are 5x bigger, but there is plenty of room for that sandbox.
  - hot_gril 3y ago
    I'm guessing it's a shared systemwide decoder that happens to be exploitable in Message, but idk.
    - saagarjha 3y ago
      That's correct, it's the WebP parser.
tester756 3y ago
It's hard to give examples because "advanced 0-days" may mean everything but somehow our society still moved everything to digital world and hasn't collapsed yet meanwhile there are definitely shitton of highly motivated people trying to break systems so, it is somehow possible to writer *safer* systems
irundebian 3y ago
Software written in Ada/SPARK.
postalrat 3y ago
How can a 0-day exist if its not possible for that software?
Dylan16807 3y ago
That depends entirely on what the software needs to do. For image decoding in particular, you can put the software into an exceptionally restrictive sandbox, or use a language that builds in the same restrictions. No I/O. No system calls. Just churn internally and fill a preallocated section of memory with RGBA. The broader system will still have weaknesses, but it won't have this kind, and this kind keeps happening.
- vilunov 3y ago
  What exactly is "an exceptionally restrictive sandbox"? There are virtual machines such as JVM, V8, or even QEMU. These are sandboxes, which run either some special bytecode or native code with extreme performance drawbacks. Media decoders are performance- and energy-sensitive pieces of software in the end. And media decoders actually ARE sandboxes of sorts. They are designed to interpret media formats, sometimes even Turing-complete bytecode in retrictive and isolated environments. And like any sandboxes, they too have bugs.
  - Dylan16807 3y ago
    > JVM, V8, or even QEMU > extreme performance drawbacks That's just not true. > And media decoders actually ARE sandboxes of sorts. They are designed to interpret media formats, sometimes even Turing-complete bytecode in retrictive and isolated environments. And like any sandboxes, they too have bugs. It's pretty easy to sandbox a simple bytecode, but that's not the bulk of what a media decoder is doing. A plain old decoder is mostly not sandboxing what it does.
- saagarjha 3y ago
  That's an awfully big preallocated array you have there. It would be pretty inefficient for that section of memory to be copied around, right? Let's map it into both processes. Also, image decoding is pretty hard, let's offload some of it to dedicated hardware. Of course, that hardware needs to have access to it mediated by the kernel. And the hardware needs to be able to access that shared memory, which was of course allocated correctly and the IOMMU setup was done correctly… You see how even simple things are difficult to secure when they have to be implemented in practice?

That's needlessly defeatist and "it's so bad out there there's no point in trying" is a thought terminating cliché. We can and should improve development practises, mitigate vulnerabities (ASLR, WAFs, etc), isolate systems from each other, and model threats in a way that we know where and how to do those things. It's not easy but just moaning "everything sucks" isn't how to fix it.

otterley 3y ago
Apple, Google, etc. have whole teams of talented people dedicated to doing exactly these types of things, and they undoubtedly help prevent many vulnerabilities from escaping the labs. Yet vulnerabilities are still created and exploited despite their best efforts. As long as software is created by imperfect humans, it will reflect the imperfections of its creators.
- mensetmanusman 3y ago
  Not only humans, the math says it’s not knowable whether any open ended hardware/software is inherently safe.
  - sudosysgen 3y ago
    It's not knowable for any, but it is knowable for some. You just have to build systems that are in the some and are inherently safe. Difficult, not impossible.
    - PradeetPatel 3y ago
      Difficult often implies additional resourcing and development related costs. Something that many companies are not willing to invest in since it will have a negative impact on the shareholder values. Often risks are accepted, and cybersecurity insurance is used to mitigate those risks.
      - sudosysgen 3y ago
        I agree, I just wanted to clarify that isn't mathematically impossible to make provably secure systems. It's just hard enough that it's not often done.
- 2OEH8eoCRo0 3y ago
  This is my take as well. If Apple and Google can't do it then what hope does anyone else have? The current paradigm is insecure and broken.
kaba0 3y ago
As sibling commenter wrote: they do exactly that. But the same way we fail to see all the cases prevented by vaccines, you only see when their work fail to work in the rare case.

hot_gril 3y ago

Or just slow. If you don't care about optimization and run things in really inefficient sandboxes, security becomes a lot easier.

Dylan16807 3y ago
How fast does iMessage image decoding need to be? And I mean this extremely rhetorically. The software launched along with the iPhone 4S. Going by geekbench, that CPU was 20-30 times weaker than a modern iPhone on a per-core basis. I know the screens on the new phones are 5x bigger, but there is plenty of room for that sandbox.
- hot_gril 3y ago
  I'm guessing it's a shared systemwide decoder that happens to be exploitable in Message, but idk.
  - saagarjha 3y ago
    That's correct, it's the WebP parser.

tester756 3y ago

It's hard to give examples because "advanced 0-days" may mean everything but somehow our society still moved everything to digital world and hasn't collapsed yet meanwhile there are definitely shitton of highly motivated people trying to break systems so, it is somehow possible to writer *safer* systems

irundebian 3y ago

Software written in Ada/SPARK.

postalrat 3y ago

How can a 0-day exist if its not possible for that software?

Dylan16807 3y ago

That depends entirely on what the software needs to do. For image decoding in particular, you can put the software into an exceptionally restrictive sandbox, or use a language that builds in the same restrictions. No I/O. No system calls. Just churn internally and fill a preallocated section of memory with RGBA. The broader system will still have weaknesses, but it won't have this kind, and this kind keeps happening.

vilunov 3y ago
What exactly is "an exceptionally restrictive sandbox"? There are virtual machines such as JVM, V8, or even QEMU. These are sandboxes, which run either some special bytecode or native code with extreme performance drawbacks. Media decoders are performance- and energy-sensitive pieces of software in the end. And media decoders actually ARE sandboxes of sorts. They are designed to interpret media formats, sometimes even Turing-complete bytecode in retrictive and isolated environments. And like any sandboxes, they too have bugs.
- Dylan16807 3y ago
  > JVM, V8, or even QEMU > extreme performance drawbacks That's just not true. > And media decoders actually ARE sandboxes of sorts. They are designed to interpret media formats, sometimes even Turing-complete bytecode in retrictive and isolated environments. And like any sandboxes, they too have bugs. It's pretty easy to sandbox a simple bytecode, but that's not the bulk of what a media decoder is doing. A plain old decoder is mostly not sandboxing what it does.
saagarjha 3y ago
That's an awfully big preallocated array you have there. It would be pretty inefficient for that section of memory to be copied around, right? Let's map it into both processes. Also, image decoding is pretty hard, let's offload some of it to dedicated hardware. Of course, that hardware needs to have access to it mediated by the kernel. And the hardware needs to be able to access that shared memory, which was of course allocated correctly and the IOMMU setup was done correctly… You see how even simple things are difficult to secure when they have to be implemented in practice?