4 ms·

Oof, another reminder that it does not matter how aggressively you fuzz, it’s still fundamentally stochastic and you can miss things like this for years :-/

by olliej 3y ago

pjmlp 3y ago
Yeah, but apparently we keep getting the feedback that with good engineering practices and good strong developers, this never comes to be.
- josephg 3y ago
  Most hackers aren’t finding their own 0days like this. If a motivated state level attacker targets you, you’re in trouble. But most companies that get hacked fail in much dumber ways - like failing to update chrome long after a bug like this has been fixed. Or using stupid, guessable passwords. Of course we should have sympathy for the 1% of companies who fall victim to 0days from state level attackers. But I have no sympathy for the other 99% of data leaks where the devs forgot to put a password on a public mongodb instance, or let their login cookies be enumerable or something equally ridiculous. Just because we can’t make security perfect doesn’t mean we shouldn’t make it good.
  - mandevil 3y ago
    James Mickens gave a lecture at a conference (I think it's this one: https://www.youtube.com/watch?v=tF24WHumvIc https://www.youtube.com/watch?v=tF24WHumvIc but I don't have time to actually listen through it) about how there are two different threat models for computer security: bored five year olds and the Mossad. And bored five year olds just try the same three things again and again, and as long as you take basic precautions you can protect yourself against them. You cannot protect yourself against the Mossad, don't even try. When I first started paying attention to computer security I was at a start-up and tasked to rewrite their PCI infrastructure for credit card processing, so I did some research into the state of the art. That week news of a casino hack came out. Billionaire casino/media magnate and conservative donor Sheldon Adelson gave a speech in October 2013 about how the US should threaten to use nuclear weapons to destroy Iran's nuclear program. In February 2014 a 150 line VB virus was installed on his casino's network which wiped all of the hard drives it could find, costing the Sands hundreds of millions of dollars. This was at a casino, some place which absolutely cares about their computer security and presumably spends a lot on that security, and they failed to successfully protect themselves against a nation-state level threat. So whatever the hell startup I was working at had no chance if someone at that level wanted it. We could stop the five year olds. Just not the nation-states.
    - tialaramex 3y ago
      None of these entities have unlimited resources or unlimited political cover. At some point you're making too big of a hole in the budget, too many people must be sacrificed and it's not worth it.
    - Timber-6539 3y ago
      Seems Youtube took down that video. I get "This video isn't available anymore."
- olliej 3y ago
  There's also the component of "there are millions of lines of existing C and C++ that continue to exist and the majority of new 'safe' languages are not designed to support gradual adoption/replacement". So you get gradual improvements to C++ that ostensibly make correct code easier (lets ignore string_view, etc) but no real path to actual safety without just rewriting everything all at once, which is an approach with a long and illustrious history of failure and major regressions even in "successful" attempts.
- deschutes 3y ago
  Is there a better way for something like an optimizing (jit) compiler? My barely informed understanding is that many of these bugs aren't soundness issues in the compilation process but instead the resulting executable code. I don't see how rust meaningfully helps with this problem. Formal verification is often thrown around but my understanding is it can't scale to the complexity of something like an optimizing compiler.
Voultapher 3y ago
I see no reason we would expect them to succeed at something no one ever has https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/ https://alexgaynor.net/2020/may/27/science-on-memory-unsafet...
- fleventynine 3y ago
  If you're generating machine code at runtime (JIT), you can have memory bugs no matter what language your JIT is written in.
  - Voultapher 3y ago
    Well maybe such a JIT is an inappropriate choice for a sandbox. There are under-explored safe alternatives such as isomorphic interpreters e.g. https://blog.cloudflare.com/building-fast-interpreters-in-rust https://blog.cloudflare.com/building-fast-interpreters-in-ru... personally I've written one such implementation that could hold it's own compared to a LLVM based JIT.
    - infamouscow 3y ago
      There's a lot of hobbyists that can compete with LLVM's JIT, and they do it without any formal training in PLT or compilers.
    - olliej 3y ago
      The whole point is the implementation and runtime for any safe language _requires_ code that is fundamentally unsafe. If you write a safe interpreter your safety is still dependent on the compiler and runtime for your safe language having no errors. This specific bug is in the implementation of a safe language, and the same can happen in any other (safe) language. People file bug reports on rustc, clang, llvm, etc all the time, and the only difference is that targeting them as an attack vector is not not particularly valuable as it's much harder to get a target to run your attack code, and the methods for doing so are much harder to hide. Note that these errors do not have to be any kind of safety error in the compiler for those languages, they can easily be erroneous codegen. These things happen. As another example, I've seen use after free bugs in WebKit and JSC come up on HN over the years, and people blame C++ memory management, when the use after failure is incorrect management of the JS GC state in the GC runtime. If you have a GCd language, then code written in that language is definitionally incapable of making memory management errors, but if you are implementing the runtime that provides that safety you are inherently and unavoidably doing things that are "unsafe" under the definition of the hosted language. The decision of many people is that JS needs to be fast, but if you disagree you can always see what the perf delta is. IIRC for non-hot code the JSC baseline JIT is maybe 10x faster than the interpreter (which is written in a pseudo assembly, so it's not taking any C/C++ overhead), and if the code is hot enough that it starts getting optimized that number just gets larger. I'm not sure what language you were compiling where your interpreter was holding its own to LLVM, but the options that would make that plausible all imply the dominant component of the runtime was not the code being interpreted. e.g. along the same lines of people comparing python performance by benchmarking C and fortran math libraries.

Oof, another reminder that it does not matter how aggressively you fuzz, it’s still fundamentally stochastic and you can miss things like this for years :-/

by olliej 3y ago

Oof, another reminder that it does not matter how aggressively you fuzz, it’s still fundamentally stochastic and you can miss things like this for years :-/

pjmlp 3y ago

Yeah, but apparently we keep getting the feedback that with good engineering practices and good strong developers, this never comes to be.

josephg 3y ago
Most hackers aren’t finding their own 0days like this. If a motivated state level attacker targets you, you’re in trouble. But most companies that get hacked fail in much dumber ways - like failing to update chrome long after a bug like this has been fixed. Or using stupid, guessable passwords. Of course we should have sympathy for the 1% of companies who fall victim to 0days from state level attackers. But I have no sympathy for the other 99% of data leaks where the devs forgot to put a password on a public mongodb instance, or let their login cookies be enumerable or something equally ridiculous. Just because we can’t make security perfect doesn’t mean we shouldn’t make it good.
- mandevil 3y ago
  James Mickens gave a lecture at a conference (I think it's this one: https://www.youtube.com/watch?v=tF24WHumvIc https://www.youtube.com/watch?v=tF24WHumvIc but I don't have time to actually listen through it) about how there are two different threat models for computer security: bored five year olds and the Mossad. And bored five year olds just try the same three things again and again, and as long as you take basic precautions you can protect yourself against them. You cannot protect yourself against the Mossad, don't even try. When I first started paying attention to computer security I was at a start-up and tasked to rewrite their PCI infrastructure for credit card processing, so I did some research into the state of the art. That week news of a casino hack came out. Billionaire casino/media magnate and conservative donor Sheldon Adelson gave a speech in October 2013 about how the US should threaten to use nuclear weapons to destroy Iran's nuclear program. In February 2014 a 150 line VB virus was installed on his casino's network which wiped all of the hard drives it could find, costing the Sands hundreds of millions of dollars. This was at a casino, some place which absolutely cares about their computer security and presumably spends a lot on that security, and they failed to successfully protect themselves against a nation-state level threat. So whatever the hell startup I was working at had no chance if someone at that level wanted it. We could stop the five year olds. Just not the nation-states.
  - tialaramex 3y ago
    None of these entities have unlimited resources or unlimited political cover. At some point you're making too big of a hole in the budget, too many people must be sacrificed and it's not worth it.
  - Timber-6539 3y ago
    Seems Youtube took down that video. I get "This video isn't available anymore."
olliej 3y ago
There's also the component of "there are millions of lines of existing C and C++ that continue to exist and the majority of new 'safe' languages are not designed to support gradual adoption/replacement". So you get gradual improvements to C++ that ostensibly make correct code easier (lets ignore string_view, etc) but no real path to actual safety without just rewriting everything all at once, which is an approach with a long and illustrious history of failure and major regressions even in "successful" attempts.
deschutes 3y ago
Is there a better way for something like an optimizing (jit) compiler? My barely informed understanding is that many of these bugs aren't soundness issues in the compilation process but instead the resulting executable code. I don't see how rust meaningfully helps with this problem. Formal verification is often thrown around but my understanding is it can't scale to the complexity of something like an optimizing compiler.

Voultapher 3y ago

I see no reason we would expect them to succeed at something no one ever has https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/ https://alexgaynor.net/2020/may/27/science-on-memory-unsafet...

fleventynine 3y ago
If you're generating machine code at runtime (JIT), you can have memory bugs no matter what language your JIT is written in.
- Voultapher 3y ago
  Well maybe such a JIT is an inappropriate choice for a sandbox. There are under-explored safe alternatives such as isomorphic interpreters e.g. https://blog.cloudflare.com/building-fast-interpreters-in-rust https://blog.cloudflare.com/building-fast-interpreters-in-ru... personally I've written one such implementation that could hold it's own compared to a LLVM based JIT.
  - infamouscow 3y ago
    There's a lot of hobbyists that can compete with LLVM's JIT, and they do it without any formal training in PLT or compilers.
  - olliej 3y ago
    The whole point is the implementation and runtime for any safe language _requires_ code that is fundamentally unsafe. If you write a safe interpreter your safety is still dependent on the compiler and runtime for your safe language having no errors. This specific bug is in the implementation of a safe language, and the same can happen in any other (safe) language. People file bug reports on rustc, clang, llvm, etc all the time, and the only difference is that targeting them as an attack vector is not not particularly valuable as it's much harder to get a target to run your attack code, and the methods for doing so are much harder to hide. Note that these errors do not have to be any kind of safety error in the compiler for those languages, they can easily be erroneous codegen. These things happen. As another example, I've seen use after free bugs in WebKit and JSC come up on HN over the years, and people blame C++ memory management, when the use after failure is incorrect management of the JS GC state in the GC runtime. If you have a GCd language, then code written in that language is definitionally incapable of making memory management errors, but if you are implementing the runtime that provides that safety you are inherently and unavoidably doing things that are "unsafe" under the definition of the hosted language. The decision of many people is that JS needs to be fast, but if you disagree you can always see what the perf delta is. IIRC for non-hot code the JSC baseline JIT is maybe 10x faster than the interpreter (which is written in a pseudo assembly, so it's not taking any C/C++ overhead), and if the code is hot enough that it starts getting optimized that number just gets larger. I'm not sure what language you were compiling where your interpreter was holding its own to LLVM, but the options that would make that plausible all imply the dominant component of the runtime was not the code being interpreted. e.g. along the same lines of people comparing python performance by benchmarking C and fortran math libraries.