A new Chrome 0-day is sending the Internet into a new chapter of Groundhog Day | Hacker News Reader

A new Chrome 0-day is sending the Internet into a new chapter of Groundhog Day

arstechnica.com

68 pointsBender35 comments

> Pages here and here list hundreds of packages for Ubuntu and Debian alone that rely on the library known as libvpx. Most browsers use it, and the list of software or vendors supporting it reads like a who’s who of the Internet, including Skype, Adobe, VLC, and Android.

I guess there's a trade-off between reinventing the wheel vs. being open to 0-days that take down a lot of projects at a time.

The upside is of the current situation is that it will likely be patched more quickly than a smaller project would be able to since everyone will be looking at libvpx right now. One shared library update will fix a lot of programs, though if they use snap or flatpack or statically include it then it will be more of a mess.

How many packages send untrusted input to the encoder though? It's a vulnerability in the context of a browser because the browser provides to any page, the ability to send arbitrary malformed data to the encoder.

Many applications present images from untrusted sources. I'm having a hard time thinking of a single application that will _encode_ untrusted input, beyond a browser.

I would assume any website which stores and displays video transcodes them to known internal specs and format. YouTube certainly does.

It's a vulnerability that needs to be patched and may have major impacts on some services.

It's _not_ a vulnerability that needs to be mentioned alongside the webp cve lest the public be caught unaware of something they need to update on every phone and laptop they own.

> there's a trade-off between reinventing the wheel vs. being open to 0-days that take down a lot of projects at a time.

I have come to think about it more as comparative advantage of different programmers and their training / skill set. Not everyone has the skills to write a complex state machine for stream encoding (I haven’t read up on libvpx, so forgive me if I mischaracterized it). We shouldn’t expect a huge diversity of available libraries to do this task.

But we should have more tools to inform the consumer of libraries to see their risk from any individual library and there should be more transparency about alternatives/substitutes to make sure we don’t see a monoculture around an inferior library if a superior option exists.

We should expect specialists to write specialized code. But we should also have QA specialists (and hopefully lots of automation) review the code. And the more systems a library is installed on, the more verification/scrutiny should be put on that code. This is the strategy of Project Zero (Google’s 0day hunting project) and lots of other organizations should contribute similar efforts.

Note that this is a vulnerability in the encoder, not the decoder.

I think this should do it for a quick patch, loaded first into every javascript execution context:

    window.MediaStreamTrack = undefined
    window.RTCPeerConnection = undefined
    window.RTCSessionDescription = undefined
    window.webkitMediaStreamTrack = undefined
    window.webkitRTCPeerConnection = undefined
    window.webkitRTCSessionDescription = undefined

We've had one in Libwebp and now it's libvp8 turn.....

i like the naivety the page painted C in a bad light because its 50 years old

> There are other similarities between the two zero-days. They both stem from buffer overflows that allow remote code execution with little or no interaction on the part of an end user other than to visit a malicious webpage. They both affect media libraries that Google published more than a decade ago. And both libraries are written in C, a 50-year-old programming language widely regarded as unsafe because it’s prone to memory-corruption vulnerabilities.

Is there something inaccurate or naive in this paragraph?

To be fair, 50 years ago security wasn't as proeminent as today. (Telnet anyone?)

Even the way to write C is not the same as 10 years ago.

But habits are hard to change. Forcing a change by changing the language is effective. Also, having languages that do more checks is also an option, but has performance impacts.

In the end, the weakest link is always the coder. Much more nowadays as they are asked to emit feature faster and faster.

Safe system programming was already an issue in the 1960's, ESPOL/NEWP already had unsafe code blocks.

I have no experience with media encoders/decoders but I have a feeling that you have no choice then work with raw bytes and not with high level wrappers because of speed, so I bet you will find similar issues in other languages if anyone wrote such a library in something else then C.

Working with raw bytes is not the problem, out-of-bounds writes is the problem. A language can allow you to read and write raw bytes while still ensuring (either statically or at runtime) that you aren't able to access memory that isn't yours.

Rust was created for the purpose of having a way to write such code while avoiding this class of issue. And the original use case was specifically to make it easier to make browsers more secure.

It's just that there is a lot of legacy code, and the migration to languages like Rust will take a long time.

This vulnerability in libvpx is in boring setup code that runs literally once, and it wouldn't matter if it was 100x slower.

Codecs have a lot of "glue" code handling configuration, I/O, and other stuff besides their most performance sensitive bit-pushing loops.

But this safe-or-fast dilemma has been mostly solved with Rust (and Wuffs). I am writing codecs in Rust.

Rust has many zero-cost abstractions (high level wrappers that get inlined, and compiled for specific types and values you use them with, and it gets optimized as concrete low-level code). This allows writing a lot performance-sensitive code using safe Rust. For example, you don't get redundant bounds checks if you use iterators, and despite being high-level abstraction with chains of iterators and closures, they compile to simple loops, and may even get vectorized (even more so than C, thanks to Rust's stronger no-aliasing and immutability guarantees).

When you need something more adventurous, you can dress it in a safe (compiler-verified) higher-level abstraction on top of minimal amount of unsafe code. Even though the underlying unsafe code is as unsafe as C, making a small component out of it helps to review/test/fuzz it in isolation against its interface, rather than test it as part of a complex algorithm.

yea this is where i was gunna go, agreed

And did you miss all the reasons people gave why that interpretation is itself naive?

C's unchecked memory access is the problem, and modern languages have solved it while still allowing writing byte-level code. Claiming that any other language that allows reading and writing raw bytes would have the same issue simply shows you do not understand the problem or the many solutions already available.

it is also possible to write secure c code, as it is in any other language.

New rule: If as a company you are providing software which is unsafe you are 100% liable for all damages. I am tired of this casual attitude towards safety.

That's a great way to make sure no company ever releases anything open source.

Not just FOSS: Depending on the phrasing, that sounds like a great way to kill gratis software as well.

No, only unsafe gratis software would be killed.

...right, so that's virtually all of it. Practically speaking, all software has bugs, and any piece of software can if nothing else be used in a chained attack to cause harm.

> Practically speaking, all software has bugs

This may change in future, e.g. by enough people turning to formal verification.

> any piece of software can if nothing else be used in a chained attack to cause harm

Does it mean that it is unsafe? In that case notion of safety seems to be destroyed.

> This may change in future, e.g. by enough people turning to formal verification.

It's been over 50 years; I don't think we're on the cusp of creating perfect software. Even formal verification and related methods - while a huge improvement! - aren't a silver bullet (AIUI, mostly in the "is your model right" and "does your theoretical analysis map to reality" points).

> Does it mean that it is unsafe? In that case notion of safety seems to be destroyed.

Yes, that's my point. If your software has exploitable bugs, it can be used in a chain of exploits to achieve attacks that don't appear plausible from individual components, and this means that most systems have a lot more attack surface than anyone wants to think about.

I mean if it doesn't have bugs. Like if someone uses a calculator, a map, other utilities in order to plan a mass shooting. If bugs may be there, notion of safety is fine.

Please define “unsafe”. Also, you can use most things in a harmful way…

Cool, but that should be directed to tomjen3.

As for myself, maybe: "that which causes loss or injury to the user when handling of it does not intend this"?

In many industries, e.g. biotech, this is how it works. Every product is vetted so much and has so many regulations to follow and liability to cover, the profit margins are not as big as software companies. I argue that is one of the main reasons we see so many breaches and also why software developers are paid so much compared to, say, a biopharma scientist.

Thats a really good point. But then this is not a new type of attack, it is literally checking that you don't overflow your allocated buffer. It has been a known attack vector for 30 years.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY

Just as disclaimers on dump trucks not being responsible for window damage, and that you cannot declare bankruptcy by just jelling it out, if the law changes this disclaimer will no longer be valid.

Completely useless in most juridisions if someone decides to go court.

What we are missing is that most people still don't do it as frequently as in other industries.

Looking forward to the day this becomes common legislation.

Reply on news.ycombinator.com