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

31–40 of 235 posts

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

#31

Post by eviks »

matheusmoreira wrote: post #13
api wrote: 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…

We simply don't appreciate other people imposing their will on us. We should be able to start a C project in 2023 without shame if we want to. Simply because we like C and don't like Rust. There's literally no need to justify it any further. We are free to do what we want. If in doubt, remember: the software is distributed in the hopes it will be useful but with ABSOLUTELY NO WARRANTY OF ANY KIND.

What's the mechanism for imposing their will?

And how is the limitation of LEGAL liability relevant in the realm of moral one (shame etc)

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

#32

Post by albntomat0 »

matheusmoreira wrote: post #13
api wrote: 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…

We simply don't appreciate other people imposing their will on us. We should be able to start a C project in 2023 without shame if we want to. Simply because we like C and don't like Rust. There's literally no need to justify it any further. We are free to do what we want. If in doubt, remember: the software is distributed in the hopes it will be useful but with ABSOLUTELY NO WARRANTY OF ANY KIND.

There's a substantial difference between a hobbyist writing a random project in C, and Google writing an image processing implementation, and then including it in Chrome and Android.

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

#33

Post by mrtksn »

albntomat0 wrote: post #26
postalrat wrote: post #19

Earlier quoted context omitted.

Is JavaScript a memory safe language?

Yes, and so are Python, Lisp, Haskell, and a million other languages that were available in 2010. None of those are suitable options for an image decoding library on the range of WebP supported platforms.

>None of those are suitable options for an image decoding library on the range of WebP supported platforms.

What makes these unusable for this task?

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

#34

Post by delfinom »

ojii wrote: post #30
ramesh31 wrote: post #17

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

Hubris and people thinking they can safely code in memory unsafe languages (they can't)

Not to worry, there are serialization and other vulnerabilities in memory safe languages :3

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

#36

Post by mnw21cam »

Vt71fcAqt7 wrote: post #27
londons_explore wrote: post #15

Earlier quoted context omitted.

Android phones don't have an awful lot of attack surface area for typical users though. Messenger apps already will refuse to display arbitrary images - Whatsapp for example will only display jpegs and mp4's sent from other contacts.

True, and most websites will reencode images for compression anyway. But the point still stands this makes "hacked by clicking a link" a reality again for some people which should have ended along with flash and java applets. The current mainstream is that "you won't get hacked if you don't install." (not to say that this is the best security practise..) Since you don't install images most people will just assume the…

Agreed. Security shouldn't depend on not visiting certain web sites, because if nothing else the ad networks are able to get your browser to load all sorts of content from all sorts of places that you wouldn't deliberately do.

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

#37

Post by sp332 »

mrtksn wrote: post #33
albntomat0 wrote: post #26

Earlier quoted context omitted.

Yes, and so are Python, Lisp, Haskell, and a million other languages that were available in 2010. None of those are suitable options for an image decoding library on the range of WebP supported platforms.

>None of those are suitable options for an image decoding library on the range of WebP supported platforms. What makes these unusable for this task?

They need a large runtime and are slow to start up.

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

#38

Post by Filligree »

Vt71fcAqt7 wrote: post #27
londons_explore wrote: post #15

Earlier quoted context omitted.

Android phones don't have an awful lot of attack surface area for typical users though. Messenger apps already will refuse to display arbitrary images - Whatsapp for example will only display jpegs and mp4's sent from other contacts.

True, and most websites will reencode images for compression anyway. But the point still stands this makes "hacked by clicking a link" a reality again for some people which should have ended along with flash and java applets. The current mainstream is that "you won't get hacked if you don't install." (not to say that this is the best security practise..) Since you don't install images most people will just assume the…

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.

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

#39

Post by jsnell »

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…

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)

Post reply on HN