Live data from Hacker News

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

stackdiary.com

221–230 of 235 posts

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

#221

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.

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/... I don't think there is any evidence to support that bounds checking causes any significant increase in power consumption, an…

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

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

#222
post #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…

Many of those devices also have Ada, Pascal and BASIC compilers available, all of which do bounds checking.

Or they can, I don't know, at very least use C++ with std::array and std::span instead of raw C arrays, with the compiler flags to do bounds checking.

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

#223

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…

I would only accept such PR with profile data and benchmarks proving the point.

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

#224
post #148

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…

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.

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

#225
post #190

How can buffer overflows still be happening in this day and age?

Buffer overflows are bugs. You're asking how bugs can still be happening in this day and age? The answer is inadequate testing and broken engineering processes.

Bugs will always exist. Bugs that lead to unbounded harmful behavior of your program are an important distinction.

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

#226
post #190

Earlier quoted context omitted.

Buffer overflows are bugs. You're asking how bugs can still be happening in this day and age? The answer is inadequate testing and broken engineering processes.

The question is how buffer overflows can still be happening, not bugs in general. No matter how bad my eng practices are, I cannot create a buffer overflow bug in a memsafe language.

Buffer overflows happen because a bounds check is missing. Using a language with implicit bounds checking (memsafe?) does _not_ excuse you from explicit bounds checking. Depending upon the language an implicit bounds check might "recover" by intentionally crashing or raising an exception. Either approach could result in lost or corrupt data with the latter being arguably worse as the program continues running in a potentially broken state. Bounds checking is error checking and non-trivial applications need robust error checking and recovery regardless of the language they are written in.

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

#227
post #133
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.

On this note, I was really surprised to find Red Hat's OCI runtime is written in C: https://github.com/containers/crun Is anyone working on a Rust version?

There is https://github.com/containers/youki

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

#228
post #8
post #7

Earlier quoted context omitted.

Downvotes of course. Programmers like to think they can write secure code with no guardrails. The fact that CVE lists are full of memory errors in 2023 says otherwise. Even if you can write secure code in unsafe languages, it’s still a problem. Bugs creep in over time as more people work on a project, changes are merged, it’s ported to other platforms, etc. If your project has any longevity you can’t bet on your pris…

Downvotes because we are tired of the rust spam.

I've been in tech for ages and I hate fads, and consider myself decent at spotting them. I was skeptical when I first started seeing Rust stuff but then I tried the language.

Definitely not a fad. It's a real innovation. Not the best language ever for language nerds / purists, but it brings a lot of important innovations down into the realm of the practical stuff you can easily use for real projects.

The only way it's going away is if something dramatically superior appears. Language design is very very hard and most "advanced" languages are impractical for real world use for various reasons, so I am not holding my breath.

The other newish language I like is Go, but for different use cases. Has a different design philosophy and imposes less cognitive load, but it's also designed for a different niche.

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

#229
post #219

Earlier quoted context omitted.

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

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

#230
post #223

Earlier quoted context omitted.

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

I would only accept such PR with profile data and benchmarks proving the point.

The dropbox article others and myself have linked provided such benchmarks, for an 11% speedup. Seem plausible?
Post reply on HN