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

11–20 of 235 posts

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

#11

Post by kevincox »

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 verify. I suspect the cost would be relatively small. Small enough that I personally would be happy to pay it.

https://github.com/webmproject/libwebp/commit/902bc919033134...

This is also a great reminder that fuzzing isn't a solution to memory unsafe languages and libraries. If anything the massive amount of bugs found via fuzzing should scare us as it is likely only scratching the surface of the vulnerabilities that still lie in the code, a couple too many branches away from being likely to be found by fuzzing.

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

#12

Post by gjsman-1000 »

mnw21cam wrote: post #3

The point about Android is particularly important. I wouldn't like to estimate the proportion of Android phones that are in regular use that no longer receive security updates.

I’m surprised, given the history of exploits, Google didn’t decide to start shipping the image decoders as an APEX system component in the Play Store, with the built-in ones serving as a fallback. They just might now.

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

#13

Post by matheusmoreira »

api wrote: post #7
0xParlay wrote: post #2

[flagged]

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.

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

#14

Post by londons_explore »

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…

Looks pretty correct to me...

We just keep track of the table size and make it bigger if necessary.

We additionally have a mode where we just calculate the necessary size, without writing any data structures.

So we have kinda added double safety against this particular bug.

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

#15

Post by londons_explore »

mnw21cam wrote: post #3

The point about Android is particularly important. I wouldn't like to estimate the proportion of Android phones that are in regular use that no longer receive security updates.

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.

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

#16

Post by albntomat0 »

Additional timeline info, as I was curious myself. WebP is old enough that a memory safe language was not a feasible option when the project started.

Android 12 was the first version to support Rust code, and came out in 2021 [0, link talks about the first year of integration].

On the iOS side (which also was affected by this), Swift 1.0 came out in ~2014.

As far as I can tell, Chrome doesn't yet support a memory safe language, but do have a bunch of other safety things built in (see MiraclePtr, sandboxing, etc). Since both WebP and Chrome are from Google, this would stop a possible transition.

WebP was announced in 2010, and had its first stable release in 2018 [1].

[0]: https://security.googleblog.com/2022/12/memory-safe-language...

[1]: https://en.wikipedia.org/wiki/WebP

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

#18

Post by nickcw »

Android is particularly troublesome here with the number of phones out there receiving no updates, and just a single download away from being exploited.

For me, personally, it's a race to see if Google can get this patched for my Pixel 5 before security updates stop in October.

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

#19

Post by postalrat »

albntomat0 wrote: post #16

Additional timeline info, as I was curious myself. WebP is old enough that a memory safe language was not a feasible option when the project started. Android 12 was the first version to support Rust code, and came out in 2021 [0, link talks about the first year of integration]. On the iOS side (which also was affected by this), Swift 1.0 came out in ~2014. As far as I can tell, Chrome doesn't yet support a memory saf…

Is JavaScript a memory safe language?

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

#20

Post by tgv »

gjsman-1000 wrote: post #12
mnw21cam wrote: post #3

The point about Android is particularly important. I wouldn't like to estimate the proportion of Android phones that are in regular use that no longer receive security updates.

I’m surprised, given the history of exploits, Google didn’t decide to start shipping the image decoders as an APEX system component in the Play Store, with the built-in ones serving as a fallback. They just might now.

I'm always suspicious of Google's behavior. It might be a good opportunity for them to tell everyone they need the latest version of Chrome because security. Manifest 3.0 and cohorts/FLoC, you can't escape them.
Post reply on HN