Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

stackdiary.com

Post reply on HN
Print view View original

211–220 of 235 posts

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

#211

Post by nahsra »

Zigurd wrote: post #160
nahsra wrote: post #153

Earlier quoted context omitted.

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 t…

I don't think specialized training solves any of the problems I mentioned. It doesn't increase the window size, or provide any of the types of highly specialized and optimized multi-file, multi-technique analysis, or make it any cheaper.

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

#212

Post by nahsra »

lukeschlather wrote: post #165
nahsra wrote: post #153

Earlier quoted context omitted.

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 am surprised that you can even say "it's not very good." The sorts of prompts I'm imagining I would expect to trigger the "I'm afraid I can't do that Dave" safeguards every time. I guess yeah, I'm just imagining using it as an advanced fuzzer but I think the thing about using an LLM is you can take the fuzzer code and ask the LLM to just generate slight variations, feed that into a test and ask the LLM to flag ones…

I don't have any problem getting it to help with exploit development. I never had any issue with that with any of them, in fact, which is surprising in retrospect.

Inference is so slow, and almost everything about fuzzers are meant to be super fast. Maybe there's a late stage part in crash validation/analysis where you can use it but my bias is that we're just not there yet.

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

#213

Post by matheusmoreira »

howinteresting wrote: post #110
matheusmoreira wrote: post #13

Earlier quoted context omitted.

We simply don't appreciate other people imposing their will on us. We should be able to start a C project in 2023 without shame if we want to. Simply because we like C and don't like Rust. There's literally no need to justify it any further. We are free to do what we want. If in doubt, remember: the software is distributed in the hopes it will be useful but with ABSOLUTELY NO WARRANTY OF ANY KIND.

Freedom of speech is not freedom from consequences. You can start your project in C and release it on an AS IS basis, and we can make fun of you for it, object to its use in professional contexts, and so on.

> we can make fun of you for it

Don't complain about the downvotes or the well-deserved replies then.

> object to its use in professional contexts

Liability limitation is standard legal boilerplate in literally every free software and open source license. No doubt it's also present in the terms of service documents which nobody reads before accepting. If you're gonna object to using software based on that, you might find you'll have to rewrite all of it or pay top dollar for service level agreements.

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

#214

Post by matheusmoreira »

eviks wrote: post #31
matheusmoreira wrote: post #13

Earlier quoted context omitted.

We simply don't appreciate other people imposing their will on us. We should be able to start a C project in 2023 without shame if we want to. Simply because we like C and don't like Rust. There's literally no need to justify it any further. We are free to do what we want. If in doubt, remember: the software is distributed in the hopes it will be useful but with ABSOLUTELY NO WARRANTY OF ANY KIND.

What's the mechanism for imposing their will? And how is the limitation of LEGAL liability relevant in the realm of moral one (shame etc)

> And how is the limitation of LEGAL liability relevant

It sure as hell matters when a guy comes here posting about how C programmers need to be sued for negligence. Can you imagine some asshole suing you because you started a project on GitHub but didn't use one of the approved languages?

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

#215

Post by Lockal »

matthewdgreen wrote: post #49
albntomat0 wrote: post #16

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.

There are already huffman-decoding and some parts of webp algorithms in https://github.com/google/wuffs (language that finds missing bounds checks during compilations). In contrary, according to readme, this language allows to write more optimized code (compared to C). WEBP decoding is stated as a midterm target in the roadmap.

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

#216

Post by namibj »

pclmulqdq wrote: post #185
aidenn0 wrote: post #139

Earlier quoted context omitted.

The past 40+ years of CS research has created a huge number of tools for reducing the costs of memory safety. Some of these made it into Rust, but others are sitting in (often abandoned) academic projects. It is an abject failure of industry that we are still parsing untrusted input in languages like C. WebP gets a slight pass because the code is so old; WebP is at least partly based on code from On2 that extends bac…

C and C++ are often used because at the optimization level that these sorts of libraries use, Rust makes tradeoffs that do not work out to 0 overhead. I would personally suggest that Google et al invest in figuring out how to make "formally-verified C" a more widely adopted language for libraries that are truly security-critical.

C safe enough to use for parsing untrusted input like this needs to be either formally verified to be safe (not to be correct, at least it's it's the canonical implementation), or written in an intrinsically memory-safe way which humans can fully reason about the safety of. And at that latter point it's slower than Rust. (Not too mention that Rust's awareness of memory lifetimes enables substantial optimizations beyond plain C code that quite often result in faster code at the same level of effort.)

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

#217

Post by namibj »

PhilipRoman wrote: post #115
AnthonyMouse wrote: post #109

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…

Indeed, I would kill for a proof assistant that integrates with C

Check out the tooling from the seL4 project. I'm aware they used intermediate levels between raw C and the proof assistant, but I don't see why that should be prohibitive.

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

#218

Post by eviks »

matheusmoreira wrote: post #214
eviks wrote: post #31

Earlier quoted context omitted.

What's the mechanism for imposing their will? And how is the limitation of LEGAL liability relevant in the realm of moral one (shame etc)

> And how is the limitation of LEGAL liability relevant It sure as hell matters when a guy comes here posting about how C programmers need to be sued for negligence. Can you imagine some asshole suing you because you started a project on GitHub but didn't use one of the approved languages?

Oh, sorry, the original comment was flagged, so didn't see the legal threat, so only made the connection between statements in your comment

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

#219

Post by pjmlp »

chlorion wrote: post #201
eqvinox wrote: post #199

Earlier quoted context omitted.

The design of io_uring has nothing to do with the language the Linux kernel is implemented in. And safer languages really can't provide guarantees when the issue at hand is designing a shared memory cross-executable (kernel⋄userspace) API.

Just having first class slice types, where your pointer is paired with a length, which allows for doing bounds checking automatically is a huge upgrade over C, even if it doesn't solve every other problem. Security exploits from out of bounds access should not be happening today, bounds checking is a solved problem, and has been solved for decades.

Time to make the point that not even C authors were able to change WG14 mind on the necessity of having fat pointers.

https://www.bell-labs.com/usr/dmr/www/vararray.pdf

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

#220

Post by pjmlp »

pclmulqdq wrote: post #185
aidenn0 wrote: post #139

Earlier quoted context omitted.

The past 40+ years of CS research has created a huge number of tools for reducing the costs of memory safety. Some of these made it into Rust, but others are sitting in (often abandoned) academic projects. It is an abject failure of industry that we are still parsing untrusted input in languages like C. WebP gets a slight pass because the code is so old; WebP is at least partly based on code from On2 that extends bac…

C and C++ are often used because at the optimization level that these sorts of libraries use, Rust makes tradeoffs that do not work out to 0 overhead. I would personally suggest that Google et al invest in figuring out how to make "formally-verified C" a more widely adopted language for libraries that are truly security-critical.

People should learn to use profilers, not even C and C++ do zero overhead versus writing in pure Assembly.

Maybe WEBP should have been written in Assembly, all the speed and I bet quite safe. /s

Post reply on HN