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

91–100 of 235 posts

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

#91

Post by pjmlp »

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.

No worries, in a couple of years you will be able to get goverment clearance for C, in similar way companies have to when dealing with hazardous substances.

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

#92

Post by reitzensteinm »

toomuchtodo wrote: post #81
malfist wrote: post #77

Earlier quoted context omitted.

Why would you expect that? LLMs are explicitly trained on what humans do. Humans miss security vulnerabilities all the time.

Because the LLM based appsec products I've tested on a large code base have been very good at finding what devs and appsec code reviews didn't.

Which ones, out of curiosity?

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

#93

Post by mrtksn »

sp332 wrote: post #37
mrtksn wrote: post #33

Earlier quoted context omitted.

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

Is that true for all memory safe languages? Why?

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

#94

Post by pclmulqdq »

kevincox wrote: post #79
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.

They aren't wasted if they are preventing security vulnerabilities. I also wouldn't be surprised if patching, rebuilding and distributing this fixed version of libwebp to all of these devices would be comparable to the extra cost of decoding.

"Preventing security vulnerabilities" is not an unadulturated good (the most secure computer does nothing but checking to make sure it hasn't been breached), and any bounds check that does not actively prevent an intrusion is wasted from a value perspective.

Your intuition about the cost of a patch vs the extra instructions in the hot path to check bounds everywhere is also very much wrong: the cost of a patch (which is also amortized among many fixes) is not even close. The hot path adds up when you call it a lot.

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

#95

Post by saghm »

izacus wrote: post #45
kevincox wrote: post #41

Earlier quoted context omitted.

I understand that the patch is correct. The point that I am trying to make is that the correctness of this code relies on non-local reasoning (the allocation/reallocation of the table before it is used). I believe that non-local reasoning raises the chance of error (and is likely one of the reasons why this bug existed in the first place). By adding length counts and explicit bounds checks locally you provide local r…

[flagged]

The best solution to this sort of bug is not using languages that are susceptible to this sort of bug. At the very least, I think it's time to retire the fallacy that we're generally capable of producing sound programs in memory unsafe languages. Just like we don't write code manually checking raw SQL to protect against injections and we don't roll our own crypto when we need to encrypt something or do a key exchange, we shouldn't treat writing safe code in C as something anyone can do by just being vaguely diligent.

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

#96

Post by Dwedit »

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

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

#97

Post by BeFlatXIII »

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)

But we need the performance of hand-tuning memory to save the environment and provide accessibility to legacy devices! /s

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

#98

Post by Helmut10001 »

sva_ wrote: post #74
matthewdgreen wrote: post #43

Earlier quoted context omitted.

A phone released in October 2020 is about to stop getting security updates?!

It appears so: https://support.google.com/pixelphone/answer/4457705?hl=en#z...

Can this be fixed with a rooted Pixel with Lineage OS?

Looks like this is it [1] and it looks like LineageOS 17 is supported even back to Pixel 3a [2].

[1]: https://review.lineageos.org/c/LineageOS/android/+/366611

[2] https://forum.xda-developers.com/t/lineageos-17-for-pixel-3a...

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

#99

Post by himinlomax »

delfinom wrote: post #34
ojii wrote: post #30

Earlier quoted context omitted.

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

I never lock my door because burglars can break a window.

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

#100

Post by izacus »

saghm wrote: post #95
izacus wrote: post #45

Earlier quoted context omitted.

[flagged]

The best solution to this sort of bug is not using languages that are susceptible to this sort of bug. At the very least, I think it's time to retire the fallacy that we're generally capable of producing sound programs in memory unsafe languages. Just like we don't write code manually checking raw SQL to protect against injections and we don't roll our own crypto when we need to encrypt something or do a key exchange…

You do understand that's not a practical solution here, do you?
Post reply on HN