Live data from Hacker News

Google assigns a CVE for libwebp and gives it a 10.0 score

stackdiary.com

151–160 of 235 posts

Re: Google assigns a CVE for libwebp and gives it a 10.0 score

#151

Earlier quoted context omitted.

I feel like we need for C and C++ what Typescript is for Javascript: Not a language from scratch but something which is as close as possible to the thing everyone is familiar with while doing the thing Rust does. A standard library where everything has the same names, the same kind of C++ objects and templates and RAII etc., change only this and nothing else. Because otherwise you make people learn 100 other things a…

Something like this? http://cyclone.thelanguage.org/wiki/Cyclone%20for%20C%20Prog...

That isn't the thing Rust does, and is slower, so then people won't use it.

The advantage of Rust is that you can produce efficient safe code. The disadvantage is that you have to learn a different language first, which deters adoption.

Re: Google assigns a CVE for libwebp and gives it a 10.0 score

#152

Earlier quoted context omitted.

> presumably This is a big presumption. Yes, it could happen. In practice, doing this isn't even the first tool you'd reach for in this circumstance; the compiler can and will eliminate duplicate bounds checks, so if you've hoisted it early, you shouldn't be using unchecked accesses, even if you care about performance, until you've demonstrated why the compiler isn't okay with removing them. The extra ceremony ("unsa…

> The extra ceremony ("unsafe { foo.get_unchecked(n) {" vs "foo[n]" makes this even simpler to catch in code review Right, and in said code review, the webp author could have easily said “yup, we want unsafe here because we already checked up front that the buffer shall not exceed k elements”. Sure it’s easier to see that unchecked access is happening, but when the whole point of large sections of the huffman table c…

For sure, this absolutely could (and will, at some point) happen. But security isn't only about what can happen, but what will probably happen. Each of these things introduces a possibility to catch the bug, not an impossibility that a bug would happen.

> it wouldn’t cause any additional scrutiny in a code review.

I would hope that it would at least cause a "demonstrate that this is actually necessary" review. People do do this! and sometimes, you do have to use unchecked. A famous example of this is litearally huffman coding, by Dropbox, back in 2016. They ended up providing both bounds checked and unchecked options as a flag, because they actually did measure and demonstrate that things were causing performance drops. I am curious if they'd still have the same issues today, given that a lot of time has passed, and also there were some other factors that would cause me to wonder a bit, but haven't followed up on myself. Regardless, this scenario will end up happening for good reasons at some point, the goal is to get them to happen only when they need to, and not before.

Re: Google assigns a CVE for libwebp and gives it a 10.0 score

#153
post #72

Earlier quoted context omitted.

This is the sort of thing where I am very curious to hear what happens if you fine-tune an uncensored version of GPT4 on some memory exploits like this along with the vulnerable code and ask it for more. It seems like it ought to be really good at this and I am suspicious that people in the know are afraid to talk about it publicly because it's too good at it and once people start weaponizing LLMs for this purpose we…

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 popular vulnerability classes. My speculation is that there just isn't enough literature on these vulnerability classes for it to have practical mastery of them.

Complex vulnerabilities are the emergent phenomena of multiple events across a codebase and it's dependencies, involving control flow, data flow, while missing type information and other runtime data. Even Anthropic's 100K context windows won't nearly fit it all, and if you stuff all the code into embeddings, the ability to reason across all this space will be poor.

You can train a model to ask very pointed questions about particular snippets, but wholesale LLM-based analysis to find vulnerabilities seems like it'll be extremely slow, expensive and inaccurate.

Re: Google assigns a CVE for libwebp and gives it a 10.0 score

#154
post #125

I'm tired and cranky today so this will lack subtlety, but: You don't have to use Rust but you **can't** use C. There's no reason to be finding these bugs in 2023; period, we can do better and we know how to do better, there's just no reason apart from legacy code (and even then) that you should be using memory unsafe languages in production.

Responses like this are why people still use C when it may make more sense to use a different language. Don’t just tell people, “trust me bro, never use C, there’s never a good reason”. Never make broad claims that leave no wiggle room, because the one thing that is always true is that there will be exceptional cases. Instead of saying this kind of stuff, why don’t you elucidate what circumstances exist where using C makes sense? Microcontrollers, FPGAs, glue code that can expose your API to other programming languages, maintaining an old code base already written in C, etc.

And as an aside, this is also why people don’t take security seriously. Not every bounds overflow will result in my database being breached and/or my computer being pwned. Instead of freaking out every time a bounds overflow or some sort of memory error is found, it may be useful to actually find out what the impact is. Is that code sandboxed? Is it local, or does it have access to the web? Does it request elevated permissions at any point? Does it even need elevated permissions?

There are many factors that can reduce or increase the risk factor of a bug. Security researchers need to start actually explaining the risk instead of blindly proclaiming everything as a “critical” vulnerability.

And everything I’m saying here has no bearing on this specific vulnerability. It’s in response to the general claim that every memory bug is critical.

Re: Google assigns a CVE for libwebp and gives it a 10.0 score

#155
post #58

Earlier quoted context omitted.

I hope it does hurt JPEG-XL adoption. The reference implementation is C++, and it’s nearly guaranteed to have equally worrisome bugs in it — every image library has seen those over the years. We live in 2023. We can deal with slightly worse compression until someone rewrites it in a sane language.

> We live in 2023. We can deal with slightly worse compression until someone rewrites it in a sane language. not just sanity of implementation but also reliability and compatibility {h264,jpg,zip} for life!

Yeah, I don't mess with webp, VP8, etc. I see near zero benefit to myself from that, with significant downsides.

Like, Google Meet insists on using VP8/9. Why, cause it's "free?" The strain on my laptop and extra energy usage for it to CPU-en/decode video ain't free. Zoom just uses h.264 instead of being annoying about it.

Re: Google assigns a CVE for libwebp and gives it a 10.0 score

#156

The thing that concerns me most is looking at the fix it is very difficult to see why this fix is correct. It also appears as there is lots of code without explicit bounds checks. It makes me worried because while the logic may be safe this makes the logic very complex. I wonder what the cost would be to add an explicit, local bounds check at every array access. This would serve as a backup that is much easier to ver…

Fuzzing needs to cover all important bits of the code to be useful. The problem I see is that incomplete coverage creates a false sense of security. Projects have some minimal fuzzing coverage (e.g. in oss-fuzz) and care less about quality of the code, thinking fuzzing will catch all security bugs.

Rust code needs proper fuzzing too. It takes a lot of effort to ensure everything is covered and stays covered as the code is developed. Crashing libraries or applications can be a denial of service. Sure, it's lower impact than an RCE due to a buffer overflow, but it is still a security issue.

Re: Google assigns a CVE for libwebp and gives it a 10.0 score

#157

Earlier quoted context omitted.

> ...isn't a solution to memory unsafe languages and libraries. If anything the massive amount of bugs found via fuzzing should scare us as it is likely only scratching the surface of the vulnerabilities that still lie in the code Yup. For example, the Linux code for its relatively new[1] io_uring subsystem was so memory-exploit-ridden that Google disabled it for apps on Android, and entirely on ChromeOS, and their s…

Kind of crazy we're still using monolithic kernels in 2023. Nothing about `io_uring` needs to happen with elevated privileges. I would take a large—say, 2-5x—performance hit just to escape these kinds of vulnerabilities.

but isn't the whole point of io_uring that it's more performant?

Re: Google assigns a CVE for libwebp and gives it a 10.0 score

#158
post #96

Observation: Uncompressed bitmaps, while bloated in terms of necessary bandwidth, still are provably the most secure form of bitmap -- just as uncompressed video (again, while super-bloaty and bandwidth intensive) would be... That is, to abstract, our security issue exists because: A) There is complex compression/decompression software/code; B) To implement this compression/decompression -- there are one or more look…

There were security flaws in the code that handled BMP files. These were revealed after the source code to Windows 2000 leaked. https://cve.mitre.org/cgi-bin/cvename.cgi?name=can-2004-0566

Also the iPhone TIF rendering bug famous for enabling jailbreakme

Re: Google assigns a CVE for libwebp and gives it a 10.0 score

#159

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…

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 other companies arrived at the same conclusion: Disabling it can be worth it if you’re quite sure you’ve gotten the up-front checking right. We can imagine that if Dropbox went to prod with the unchecked huffman implementation (never mind that that article isn’t about webp in particular), we could imagine they could easily have the same bug. And I don’t think a naive code review saying “unsafe is bad” would have stopped them from doing it: they clearly did the work to show why it’s worth it.

Re: Google assigns a CVE for libwebp and gives it a 10.0 score

#160
post #153
post #72

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…

I would not expect an LLM to be good at this without specialized training. I have tried prompting for code generation.

I do not know of LLMs that have been specifically trained on, say, the testing corpus of some "lint" programs and against known vulns. As you point out, it wouldn't be possible as a user of an LLM AI to do the equivalent by showing it some vulns, while it would be perfectly reasonable to get an LLM to write, for example, business case studies by showing it examples.

Post reply on HN