Looks pretty correct to me...

We just keep track of the table size and make it bigger if necessary.

We additionally have a mode where we just calculate the necessary size, without writing any data structures.

So we have kinda added double safety against this particular bug.

There was a great explanation a few days back on why the vulnerability existed, and on why the fix was correct: https://blog.isosceles.com/the-webp-0day/

(Discussed in https://news.ycombinator.com/item?id=37600852)

I understand that the patch is correct. The point that I am trying to make is that the correctness of this code relies on non-local reasoning (the allocation/reallocation of the table before it is used). I believe that non-local reasoning raises the chance of error (and is likely one of the reasons why this bug existed in the first place).

By adding length counts and explicit bounds checks locally you provide local reasoning to back up this non-local reasoning which is much *easier* to make and maintain correct. I think that would result in code that is less likely to have similar bugs in the future.

So what exactly do you propose?

ye gads man, did you even read the comment you're replying to?

I did - and I'm not sure how adding those checks here would help. Are you proposing a full library reaudit?

$ ./pedant.sh

If you read what they proposed and disagreed with it, then don't ask "What do you propose?" - Argue/debate why you think their proposal, which you read, is not useful.

The best solution to this sort of bug is not using languages that are susceptible to this sort of bug. At the very least, I think it's time to retire the fallacy that we're generally capable of producing sound programs in memory unsafe languages. Just like we don't write code manually checking raw SQL to protect against injections and we don't roll our own crypto when we need to encrypt something or do a key exchange, we shouldn't treat writing safe code in C as something anyone can do by just being vaguely diligent.

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 at once to start using it effectively, and then they don't.

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.

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.

I'm asking this into the comment section, since I'm curious if anyone has checked:

Does Zig fill this space in any way? It still allows manual memory management but offers more protections, the specifics I'm unclear on.

Zig is something like this for C, but not C++. There are a number of ongoing attempts to do something like this for C++, but it is very hard and they are all way behind Rust in terms of mindshare.

You do understand that's not a practical solution here, do you?

Implementing webp and similar libraries in another language may not be quick or easy, but having these sorts of issues continue to crop up over and over doesn't feel particularly practical to me; it's just easier to act like every time a critical vulnerability comes up due to memory safety that it's an isolated issue than confront the reality that its a systemic issue and there aren't any easy solutions.

This response is becoming so tiresome

> This response is becoming so tiresome

I'd argue the constant stream of CVEs due to memory unsafety is even more tiresome.

Agreed, I'll stop saying it when we stop having these issues. I don't think people want to confront the fact that there isn't any easier solution, but we're going to keep running into the same thing over and over until we do.

The lack of response is way more tiresome. We keep having the same catastrophic failures decade after decade. Let's do nothing.

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.

They aren't wasted if they are preventing security vulnerabilities.

I also wouldn't be surprised if patching, rebuilding and distributing this fixed version of libwebp to all of these devices would be comparable to the extra cost of decoding.

"Preventing security vulnerabilities" is not an unadulturated good (the most secure computer does nothing but checking to make sure it hasn't been breached), and any bounds check that does not actively prevent an intrusion is wasted from a value perspective.

Your intuition about the cost of a patch vs the extra instructions in the hot path to check bounds everywhere is also very much wrong: the cost of a patch (which is also amortized among many fixes) is not even close. The hot path adds up when you call it a lot.

The most secure computer does nothing, because checking if it has been breached is attack surface.

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.

> … resources browsing the web, running radios

That's the whole point of webp, though.

Not-taken branches and filling your superscalar slots with extra instructions costs 0 time, but they still cost energy.

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 back at least until the early '00s. Rewriting working code is always going to be lower priority than writing new code (and it's not always a safety win either; being deployed for 10 years gets you an awful lot of real-world testing!).

But look at implementations for newer image formats and you see more of the same; C and C++ with the token java implementation that won't get used outside of the JVM.

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.)

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

Apple has actually measured the impact of adding bounds checking to commonly used libraries including media libraries and found no impact on overall power use. Audio and video encoding libraries took around a 1% performance impact.

https://llvm.org/devmtg/2023-05/slides/TechnicalTalks-May11/...

There is no technological reason to not use bounds checking as the default mode of operation since ALGOL exists.

My favourite quote, C.A.R Hoare's "The 1980 ACM Turing Award Lecture"

"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."

-- https://www.labouseur.com/projects/codeReckon/papers/The-Emp...

> ...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 servers[2]. It is insane that this is how easy it has been for a person to break into Linux.

[1] released with kernel version 5.1 which came out in May 2019

[2] in June 2023: https://en.m.wikipedia.org/wiki/Io_uring#Security

Only goes to show that C is a broken language and unfit for its purpose in today's day and age

For people downvoting, could you please explain which part of this statement you agree or disagree with?

C is syntactic sugar around assembly. Saying C is outdated is like saying assembly is outdated. At that point, just admit you're not interested in computers

I want to create software that doesn’t harm users. That doesn’t at all imply that I’m not interested in computers. In fact guaranteeing safety for users shows a profound interest in computers.

But assembly _is_ outdated, at least for the purpose of authoring large community software projects.

> C is syntactic sugar around assembly.

The C abstract machine, and the undefined behavior shenanigans compilers are pulling off says otherwise.

> C is syntactic sugar around assembly

It isn't

As an example, see how C 'int', 'short', 'long' or whatever becomes actual different types

> just admit you're not interested in computers

I have the popcorn ready already for when the next C "hotshot" shoots himself in the foot yet again because he thinks a chainsaw without an emergency brake is just more fun

> chainsaw without an emergency brake is just more fun

Fun and fast!

> C is syntactic sugar around assembly.

Even if this is true (and I don't believe it is), it's not useful.

All programming languages are syntactic sugar around processor instructions

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

That's a pretty interesting paper. Thanks for sharing it. I wonder why Dennis Ritchie, with the weight his name carries, wasn't able to push it into mainstream implementation...

Because once a language is managed by ISO, that doesn't matter, the author gets one vote like everyone else.

So this shows how the majority of WG14 members see security in C.

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?

A 2-5× performance hit is also a 2-5× CO₂ hit, and I wouldn't be willing to let myself or other people take that hit. We're throwing enough heat into the atmosphere already to make cats dance on our portable supercomputers as is.

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 just won't be able to use memory unsafe code anymore.

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.

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.

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.

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 that look like they might have been an exploit. And when it generates nonsense code, you just throw out those runs. But on the other hand hallucination feels like an advantage here since it's going to do things you never would have thought to test.

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.

This is why I'm bullish on LLMs for application security vulnerability searches (like Shodan for code). It'll see what humans don't.

Seems to help attackers just as much as defenders though, until you’ve found every single bug (which could be possible, but will likely be expensive.)

Why would you expect that? LLMs are explicitly trained on what humans do. Humans miss security vulnerabilities all the time.

Because the LLM based appsec products I've tested on a large code base have been very good at finding what devs and appsec code reviews didn't.

Which ones, out of curiosity?

Humans can't be forced to evaluate every piece of code 100000 times in an hour. LLMs can.

With infinite hardware, sure. LLMs are pretty expensive to run vs fuzzing.

Humans find security vulnerabilities all the time too. The assumption is a lot of the misses are because highly trained security experts don't have time to carefully read and understand all code without fatigue.

Because of generalization.

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.

This isn't even the problem. There are shitloads of open bugs found by fuzzing, even in the linux kernel, that nobody is fixing. Serious security vulns in the kernel regress because of lack of tests.

It is clear that even if we stood up the best bug finding systems the world has ever seen that critical software will still be a disaster.