161–170 of 235 posts
Earlier quoted context omitted.
For people downvoting, could you please explain which part of this statement you agree or disagree with?
[flagged]
Earlier quoted context omitted.
Hubris and people thinking they can safely code in memory unsafe languages (they can't)
A memory-safe language could have easily resulted in the same vulnerability. In this context, “memory-safe” means it does bounds checking on an array when you try to access an element. But the webp code does bounds checks up-front so that array accesses can be non-checked, to help performance. (If they didn’t want this performance, they could have easily used a std::vector and used bounds-checked access.) The vulnera…
You don't have to hypothesize. It's here:
https://github.com/image-rs/image/blob/master/src/codecs/web...
and it doesn't use unsafe indexing.
Android is particularly troublesome here with the number of phones out there receiving no updates, and just a single download away from being exploited. For me, personally, it's a race to see if Google can get this patched for my Pixel 5 before security updates stop in October.
A phone released in October 2020 is about to stop getting security updates?!
Earlier quoted context omitted.
LLMs should indeed be very good at finding vulns. It is a safe bet state actors have already done this, and have added to their stockpile of zero-day exploits. I suspect you are right that collectively we are whistling past the graveyard and the current "solution" is to make widely available LLMs explicitly not provide that kind of capability.
My experience is they're not good at this for most vulnerability classes, especially the those that are tough to discover by classical methods. Have you had any experience using them for this? Trivial vulnerabilities are easily discoverable yes -- but, they are also trivially discoverable by standard automation available today. I've found GPT-4 to be shockingly bad at vulnerability analysis for all except the most po…
Earlier quoted context omitted.
Over a library used by billions of people a lot of times a day, those bounds checks add up to a lot of wasted time and energy if you don't strictly need them. If this is a common function in the webp library, this function is probably called something like a trillion times a day.
I think your intuition on the cost of not-taken bounds check branches is off, especially in the context of devices that spend most of their resources browsing the web, running radios, powering screen backlights. I bet any holistic measurement could not tell the difference.
That's the whole point of webp, though.
Earlier quoted context omitted.
Hubris and people thinking they can safely code in memory unsafe languages (they can't)
A memory-safe language could have easily resulted in the same vulnerability. In this context, “memory-safe” means it does bounds checking on an array when you try to access an element. But the webp code does bounds checks up-front so that array accesses can be non-checked, to help performance. (If they didn’t want this performance, they could have easily used a std::vector and used bounds-checked access.) The vulnera…
Earlier quoted context omitted.
A memory-safe language could have easily resulted in the same vulnerability. In this context, “memory-safe” means it does bounds checking on an array when you try to access an element. But the webp code does bounds checks up-front so that array accesses can be non-checked, to help performance. (If they didn’t want this performance, they could have easily used a std::vector and used bounds-checked access.) The vulnera…
Unsafe rust is not a memory-safe language.
Additional timeline info, as I was curious myself. WebP is old enough that a memory safe language was not a feasible option when the project started. Android 12 was the first version to support Rust code, and came out in 2021 [0, link talks about the first year of integration]. On the iOS side (which also was affected by this), Swift 1.0 came out in ~2014. As far as I can tell, Chrome doesn't yet support a memory saf…
Is Rust in practice a memory safe language when you're doing tricks like decoding huffman-decoding huffman tables into buffers? It seems like once you optimize for performance this much, you're liable to turn off bounds checking here or there.
Earlier quoted context omitted.
While yes, that's theoretically possible, do you have data to establish this? For example, having small sections of the code be marked as unsafe would allow for greater scrutiny of those sections. Also, unsafe access is more annoying to perform in Rust than in C or C++, so maybe that would have acted as a deterrent (or at least the code would have been profiled to make sure that unsafe access was worth it). https://s…
Elsewhere in the comments someone linked to this: https://dropbox.tech/infrastructure/lossless-compression-wit... It looks like dropbox experimented with disabling bounds checks in their huffman coding impl, and found that using the unsafe pattern increased throughput from 224 MB/s to 249 MB/s (11%-ish faster.) We don’t even need to hypothesize about whether webp would have elminated bounds checking, we can see that…