4 ms·

I want to respond to the strongest interpretation of your comment, but no matter how I read it, all I'm getting is "defense in depth is meaningless". Do you al

I want to respond to the strongest interpretation of your comment, but no matter how I read it, all I'm getting is "defense in depth is meaningless". Do you also think apple shouldn't have bothered building blastdoor sandboxing, since all the code running in the sandbox should just be flawless code with no security issues anyway? Is ASLR not worth it since the core problem is that there are memory safety bugs, and so we should instead just write it all in rust and not do ASLR or such? I'm not saying we shouldn't fix security issues, just suggesting a defense in depth mechanism that in practice seems like it'd make most people a lot safer.

kevin_thibedeau 2y ago
This is all a fuckup by the responsible vendor Apple who isn't comprehensively using commercial static analyzers that can easily detect this sort of buffer overflow. They both have billions in cash to pay for dedicated engineering teams to do this work.
- CharlesW 2y ago
  Are you saying it's bad that Apple's using an open source solution, or that Clang Static Analyzer (built into Xcode) is bad specifically? https://www.youtube.com/watch?v=jajgCfkLNdk https://www.youtube.com/watch?v=jajgCfkLNdk
- galad87 2y ago
  But the initial security issue was in libwebp, which is made by Google, and surely Google had already fuzzed it and run all the available static analyzers in the world. Static analyzers are nice to have, but they can't warn of every issue out there.
  - astrange 2y ago
    The initial security design failure was inventing lossless WebP, which is a completely different format from lossy WebP, which means the library has double the code for double the attack surface. I am skeptical inventing any kind of WebP was a good idea, but I know the inventor and he got mad at me last time I said that, so I won't.
    - saagarjha 2y ago
      Maybe because going "I think WebP was a bad idea" when its implementation has the same bugs in it that every other image parser has is not a very useful comment to make.
      - acdha 2y ago
        I think there’s a stronger form of the argument: image formats are expensive to create and secure, and that should have factored into WebP adoption given its marginal benefits. The lesson I hope was learned is that nobody should be writing new parsers in an unsafe language. WebP is old enough that it was defensible at the time but everyone should have a “no new C/C++” policy for internet-facing code.
        saagarjha 2y ago
        Yes, I think we’re going to see this moving forward. The tools are in place to make this possible.
      - astrange 2y ago
        No, it's a bad idea because they based it on a video codec and then released a much better video codec a year later but couldn't update it. It's not better enough than JPEG to be worth existing.
        saagarjha 2y ago
        The same could be said for half the formats Apple ships: HEIF/HEVC, for example. Or even LZFSE: who asked for an algorithm that compresses worse, slower?
        astrange 2y ago
        It could but HEVC is actually an open standard, whereas WebP is a proprietary codec they bought and then released with no community feedback. (That's why the next VPx codec was better.) Also HEIF actually has useful features, it supports HDR! AVIF is certainly better though. I only feel positively about AVIF and JPEGXL.
- ikmckenz 2y ago
  The Isosceles blog post[0] on the initial webp exploit, linked by the article, says: > Google's OSS-Fuzz project has fuzzed hundreds of open source libraries for many years now, including libwebp and many other image decoding libraries. It's possible to look in full detail at the code coverage for OSS-Fuzz projects, and it's clear that lossless support for WebP was being fuzzed extensively… In fact one of the first things that Google did after the WebP 0day was fixed was to release a new fuzzer specifically for the Huffman routines in WebP. I tried running this fuzzer for a bit (with a bit of backporting required due to API changes) and it predictably did not find CVE-2023-4863… This bug also shows that we have an over-reliance on fuzzing for security assurance of complex parser code. Fuzzing is great, but we know that there are many serious security issues that aren't easy to fuzz. So perhaps it’s not so simple as throwing a fuzzer at it. [0] https://blog.isosceles.com/the-webp-0day/ https://blog.isosceles.com/the-webp-0day/
deleted 2y ago
[deleted]

kevin_thibedeau 2y ago

This is all a fuckup by the responsible vendor Apple who isn't comprehensively using commercial static analyzers that can easily detect this sort of buffer overflow. They both have billions in cash to pay for dedicated engineering teams to do this work.

CharlesW 2y ago
Are you saying it's bad that Apple's using an open source solution, or that Clang Static Analyzer (built into Xcode) is bad specifically? https://www.youtube.com/watch?v=jajgCfkLNdk https://www.youtube.com/watch?v=jajgCfkLNdk
galad87 2y ago
But the initial security issue was in libwebp, which is made by Google, and surely Google had already fuzzed it and run all the available static analyzers in the world. Static analyzers are nice to have, but they can't warn of every issue out there.
- astrange 2y ago
  The initial security design failure was inventing lossless WebP, which is a completely different format from lossy WebP, which means the library has double the code for double the attack surface. I am skeptical inventing any kind of WebP was a good idea, but I know the inventor and he got mad at me last time I said that, so I won't.
  - saagarjha 2y ago
    Maybe because going "I think WebP was a bad idea" when its implementation has the same bugs in it that every other image parser has is not a very useful comment to make.
    - acdha 2y ago
      I think there’s a stronger form of the argument: image formats are expensive to create and secure, and that should have factored into WebP adoption given its marginal benefits. The lesson I hope was learned is that nobody should be writing new parsers in an unsafe language. WebP is old enough that it was defensible at the time but everyone should have a “no new C/C++” policy for internet-facing code.
      - saagarjha 2y ago
        Yes, I think we’re going to see this moving forward. The tools are in place to make this possible.
    - astrange 2y ago
      No, it's a bad idea because they based it on a video codec and then released a much better video codec a year later but couldn't update it. It's not better enough than JPEG to be worth existing.
      - saagarjha 2y ago
        The same could be said for half the formats Apple ships: HEIF/HEVC, for example. Or even LZFSE: who asked for an algorithm that compresses worse, slower?
        astrange 2y ago
        It could but HEVC is actually an open standard, whereas WebP is a proprietary codec they bought and then released with no community feedback. (That's why the next VPx codec was better.) Also HEIF actually has useful features, it supports HDR! AVIF is certainly better though. I only feel positively about AVIF and JPEGXL.
ikmckenz 2y ago
The Isosceles blog post[0] on the initial webp exploit, linked by the article, says: > Google's OSS-Fuzz project has fuzzed hundreds of open source libraries for many years now, including libwebp and many other image decoding libraries. It's possible to look in full detail at the code coverage for OSS-Fuzz projects, and it's clear that lossless support for WebP was being fuzzed extensively… In fact one of the first things that Google did after the WebP 0day was fixed was to release a new fuzzer specifically for the Huffman routines in WebP. I tried running this fuzzer for a bit (with a bit of backporting required due to API changes) and it predictably did not find CVE-2023-4863… This bug also shows that we have an over-reliance on fuzzing for security assurance of complex parser code. Fuzzing is great, but we know that there are many serious security issues that aren't easy to fuzz. So perhaps it’s not so simple as throwing a fuzzer at it. [0] https://blog.isosceles.com/the-webp-0day/ https://blog.isosceles.com/the-webp-0day/

deleted 2y ago

[deleted]