Hacker News Reader

Comment by TheDong | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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.

Yes, I think we’re going to see this moving forward. The tools are in place to make this possible.

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.

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?

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.

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/

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

Reply on news.ycombinator.com