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

231–235 of 235 posts

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

#231

Post by pjmlp »

ninkendo wrote: post #230
pjmlp wrote: post #223

Earlier quoted context omitted.

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?

As everything in IT, it depends.

That was for Dropbox specific use case, and 11% seems too much in any case.

For example, what improvements has had rustc in the meantime to better optimize bounds checking, it is still the same, it is less, does it actually matter on the acceptance criteria regarding the definition of done on the story.

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

#232

Post by hot_gril »

hgs3 wrote: post #226
hot_gril wrote: post #192

Earlier quoted context omitted.

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

Exception gets caught somewhere up the call stack, like a webserver returning error 500. It's not the most user-friendly error handling, so you should avoid that whenever you can, but it's not a big problem. In some languages like C++, you'll trigger a crash instead, which can be more of an issue but still isn't nearly as bad as an undetected buffer overflow.

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

#233

Post by pjmlp »

winter_blue wrote: post #229
pjmlp wrote: post #219

Earlier quoted context omitted.

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.

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

#235

Post by dureuill »

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…

The most recent high severity vulnerability I could find in libjpeg is CVE-2016-6702[0].

If you're willing to count libjpeg-turbo, there's also CVE-2020-17541[1].

For h.264, if you're willing to count Firefox or gstreamer, we're talking CVE-2022-3266 or CVE-2021-3185 (the latter is even critical)

[0]: https://nvd.nist.gov/vuln/detail/CVE-2016-6702

[1]: https://nvd.nist.gov/vuln/detail/CVE-2020-17541

Post reply on HN