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

171–180 of 235 posts

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

#171

Post by [deleted] »

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…

[deleted]

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

#172

Post by hot_gril »

vacuity wrote: post #168
e93849 wrote: post #108

Earlier quoted context omitted.

Unsafe rust is not a memory-safe language.

It isn't, but there's a big difference between writing straight C and writing some unsafe Rust with safe wrappers. It's generally possible to have comparably few lines of unsafe Rust that do the heavy lifting and can be verified to maintain memory safety without sacrificing performance.

Well, the code you mark unsafe is probably also the most complicated piece and thus the most likely to have a bug. I can trust decent C devs to write their basic logic safely, just not the hyper-optimized portions.

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

#173

Post by nikanj »

aorth wrote: post #50

> To put this in context: if this bug does affect Android, then it could potentially be turned into a remote exploit for apps like Signal and WhatsApp. I'd expect it to be fixed in the October bulletin. Interesting quote from Ben Hawkes (former Project Zero manager) in the article. I regularly compile Signal-Android from source and happened to notice they vendored libwebp a few days ago: https://github.com/signalapp/…

Fixed in the October bulletin*

*For the small fraction of Android phones that are new enough to get updates

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

#175

Post by pclmulqdq »

ctz wrote: post #131
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.

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.

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

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

#176

Post by UncleMeat »

mlichvar wrote: post #156
kevincox wrote: post #11

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

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.

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

#177

Post by Patrickmi »

radlad wrote: post #149
yjftsjthsd-h wrote: post #138

Earlier quoted context omitted.

Well runc is in Go, which isn't Rust but at least isn't C.

Yes, and Red Hat has metrics and explanations showing why Go is not exactly ideal here. And yet I am surprised they chose C as a replacement... hence my question above!

[dead]

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

#178

Post by UncleMeat »

yjftsjthsd-h wrote: post #142
Filligree wrote: post #38

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.

I was under the impression that modern C++ is a "sane language" - it looks like "smart pointers" are a thing now?

Smart pointers aren't the beginning and end of things. C++ is riddled with places that can be converted into weird machines, even if you guarantee correct lifetimes of everything on the heap.

Look at how much fun we can just have with the stack!

  std::string_view foo(std::string_view s) {
    return s;
  }

  auto s = foo("temporary");  // kaboom
Modern C++ does not force you to initialize everything before it is read. Modern C++ happily lets you ignore bounds checks with vector operator[] or by using c style arrays or by doing pointer arithmetic. Modern C++ happily lets you overflow integers or silently truncate when widths change. And on and on and on. Turning every "new" into "make_shared" is nowhere close to enough to make C++ safe in the face of bugs.

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

#179

Post by peter_d_sherman »

Pxtl wrote: post #76
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…

Yes, but as counterargument: there are battle-tested compression formats that offer pretty-damned-good compression. If anything, this shows some questions of calculus when it comes to risk-vs-reward of embracing new standards for compression formats. When was the last time there was a serious vulnerability in major JPEG libs? Or even h.264, which is much newer? Yes, a .webp is like 2/3 the size of a similar JPEG, but…

>When was the last time there was a serious vulnerability in major JPEG libs?

1) Kindly define "serious"...

2) Kindly define "major"...

Also... why can't you ask the question you pose:

"When was the last time there was a serious vulnerability in major JPEG libs?"

...with the words "serious" and "major" removed, i.e.:

"When was the last time there was a vulnerability in JPEG libs?"

?

As that might be a far better question if the generation of insight is desired...

?

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

#180

Post by peter_d_sherman »

Dwedit wrote: post #96
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…

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

Let me rephrase:

Uncompressed bitmaps with absolutely NO extraneous unnecessary "handling code" (which would have existed in the case of the Windows BMP display code, if a security flaw was found in them...).

But... all in all, doesn't surprise me...

Post reply on HN