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

181–190 of 235 posts

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

#181

Post by hot_gril »

ninkendo wrote: post #159
howinteresting wrote: post #105

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…

The risk probably doesn't matter for their use case because they're doing all this datacenter-scale image conversion on processes separate from the main logic (and likely not even on the same machines). Unlike in a phone's web browser or something, where it's 11% speedup with ??% added risk.

It's already common for PC apps to split potentially unsafe rendering into subprocesses, like in Chrome. If you don't want to pay the full IPC toll, there's shared memory. In theory should be about the same speed as inlined unsafe code, right? What if Rust's "unsafe" blocks could do this for you?

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

#182

Post by Pxtl »

yjftsjthsd-h wrote: post #144
Pxtl wrote: post #71

Earlier quoted context omitted.

Is there any site that shows what phones are still getting security updates? I'm worried that this will be the thing that makes me retire my son's old Moto G... 5 I think? It's probably out of security updates. Which kills me, he's a careful boy and it's a solid phone, this is unnecessary E-Waste.

I don't know of a site that tracks it, but in the phone settings you can see when it last got security patches. Also, if you want to get security updates without the e-waste, you could just install LineageOS on it.

"just" is definitely a 4-letter word here, but yes, I think I'll be getting him a new one and putting LineageOS on the thing to play with.

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

#183

Post by ryeights »

mxkopy wrote: post #136
Aeolos wrote: post #126

Earlier quoted context omitted.

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

[flagged]

All programming languages are syntactic sugar around processor instructions

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

#184

Post by ninkendo »

pornel wrote: post #162
ninkendo wrote: post #101

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…

> If we were to hypothesize a counterfactual world where webp was written in rust 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.

That’s not google’s webp library, that’s a totally different project. It doesn’t really matter what that project does.

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

#185

Post by pclmulqdq »

aidenn0 wrote: post #139
pclmulqdq wrote: post #75

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.

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.

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

#186

Post by peter_d_sherman »

peter_d_sherman wrote: post #59

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…

Also... many posters suggest use of Rust may be a solution...

It may turn out to be... but I think a more broader generalization of the language /compiler aspect of things may be:

Not so much to "use Rust", so much as "NOT to use C".

That is -- any library performing decompression of any sort (regardless of whether that decompression is related to visual images or not), if it uses C and lookup tables and implements decompression -- should at least be considered a potential source of future problems, and should (ideally) be migrated to a more memory-safe, bounds-checked language -- in the future.

Rust -- may or may not turn out to be this language...

Negatives for Rust -- large size and complexity of Rust's compiler source code.

Positives for Rust -- Rust's treatment of memory and bounds-checking.

Anyway, some thoughts on the language/compiler aspect of this...

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

#187

Post by peteradio »

raverbashing wrote: post #143
mxkopy wrote: post #136

Earlier quoted context omitted.

[flagged]

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

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

#189

Post by pjmlp »

assassinator42 wrote: post #140
pjmlp wrote: post #90

Earlier quoted context omitted.

Modula-2, Ada, Object Pascal, D would be. What makes them unsuitabe is lack of widespread compiler support across those platforms, if we ignore how long Ada has been available in GCC. And Modula-2 is now in GCC as well.

Ada has the bounds checking, but doesn't (AFAIK) have a safe way to deallocate dynamic memory. At least as of now, there is a proposal to add something like Rust in the future. It also has memory unsafe concepts like specifying an address for a variable.

Yes it does, this isn't Ada83 we are talking about.

Well Rust also has unsafe, better not use it.

Post reply on HN