Hacker News Reader

Comment by londons_explore | Hacker News Reader

Within Google Chrome, WebP images are decoded by the renderer, and therefore any exploit can only get renderer code execution - which is inside a sandbox.

Since the renderer is very complex, there are lots of exploits discovered each year for it. However, when someone manages to get code execution in a renderer they don't get much more access than a webpage would normally get. Specifically, they can't see or leave files on the filesystem of your machine, nor even read cookies for other domains.

View on HN

> when someone manages to get code execution in a renderer they don't get much more access than a webpage would normally get

Unless of course there is a sandbox break-out exploit to combine this with. So not an immediate priority, unless there is such an exploit in the wild that I don't know about, but important to patch as soon as not terribly inconvenient.

Well, this was exploited in the wild. Here's the actual commit for the bug fix in webp. https://chromium.googlesource.com/webm/libwebp/+/902bc91

Aye, TFA mentions that.

It doesn't say if it breached the sandbox (I'd expect another CVE if there is an active sandbox flaw also), or indeed if the exploit targeted Chrome specifically at all or the library more generally.

Feels like it must have, otherwise what would be the point? But perhaps the CVE will come from Microsoft or some other vendor, if it's Renderer -> Kernel exploit.

> otherwise what would be the point?

The exploit could be a PoC that at the moment does something noticeable but relatively innocuous. If there was a sandbox exploit that is already exploited along with this one, I'd expect this announcement to have been held back until when (or after) the other is announced.

ACE & RCE bugs should be taken this seriously even if another (as yet not known to exist) bug needs to be chained with it in order to do _real_ damage, because for all we know a black-hat out there could be sat on such a bug hoping no one else notices (and therefore it gets fixed) before something like this comes along to provide the other half of a really serious zero-day PitA.

> The exploit could be a PoC that at the moment does something noticeable but relatively innocuous.

Why would you exploit some DC lawyer with a POC?

> what would be the point?

It was initially reported as an exploit in Apple's ImageIO library, which is not properly sandboxed on iOS. https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zer...

There are two different possible attack vectors.

1. First, once you "local root" within the sandboxed process what can you compromise?

a. Can the session cookies be stolen? (Think gmail inline attachment rendering a malicious webp image).

b. Can you launch attack on other local network resources from within the compromised sandbox – read insecure filesystems, make tcp sockets to local resources etc – these are not prevented by OS sandboxing capabilities that Chrome depends on.

2. Second, can you probe for vulnerabilities in OS sandboxing that chrome depends on to break out of sandbox? On older unpatched OS versions this is definitely possible. These attack vectors may have been fixed in newer patches of OS already so you won't see a new CVE and patch for the same from the OS vendors.

Im not in security. What are the answers for 1a and b? Are they hypothetical? I assume no.

2, as they mentioned, is the separate CVE they suggested.

Here is a description of process and site isolation in Chrome:

https://chromium.googlesource.com/chromium/src/+/main/docs/p...

> b. Can you launch attack on other local network resources from within the compromised sandbox – read insecure filesystems, make tcp sockets to local resources etc – these are not prevented by OS sandboxing capabilities that Chrome depends on.

Huh? Chrome on Linux uses a network namespace to remove all networking from the renderer process, and then uses seccomp to forbid most system calls, and can very easily prevent e.g. opening new sockets with that.

https://chromium.googlesource.com/chromiumos/docs/+/HEAD/san...

https://blog.chromium.org/2012/11/a-safer-playground-for-you...

https://blog.cr0.org/2012/09/introducing-chromes-next-genera...

Ad 2. You don’t need a vulnerability in OS sandboxing. You need a way to start communicating with the browser process, since the way renderer processes do I/O is they delegate it to the browser process by communicating over a socket. With a sufficiently advanced arbitrary code execution that’s possible without trying to find bugs in the kernel.

Unrelated, what does "TFA" stand for? The only thing I can come up with is "the fucking article", which I really doubt is correct.

That is what it stands for. Inspired by RTFM I assume. I learned these on Slashdot about 20 years ago ... they made sense in that context, and have carried on as a familiar jargon ...

https://en.wiktionary.org/wiki/TFA

The Fucking Article

You can say "The Fine Article" if you're feeling nice. :)

This is correct. An alternate reading is The Friendly Article. Either way it means "the article or page being discussed"

I've always read it as The Featured Article

Same. As a shorthand reference for "the article that is under discussion" it doesn't need to convey the hostility/frustration that "RTFM" does.

Unless you're saying "Did you even read the TFA?!?" but that would violate the code of conduct around here.

Getting permissions on a single website user context is already enough considering the vast amount of user uploaded images on the modern internet. It's a bit like XSS on steroids, because it is not limited to one site or frontend.

Well websites are stupid if they don't reencode user-uploaded images for precisely this reason...

Otherwise an evil client uploads a malicious webp image, which then gets hosted and 'shared' by the server to other users, who upon viewing said image get exploited and share more malicious images...

Unless you mean the client should transcode before upload (which they can, mind) that mostly makes the server exploitable.

You'd set up the server so that it's okay if it gets exploited. For example, maybe its only job is decoding images.

If an exploit gives you remote code execution on the image transcoding server, you can simply change the transcode operation into a pass through. Hell, you could even start adding your payload to other users' uploads.

I said the decoder, not the encoder.

Then transcode in a different server.

Not transcoding user-uploaded files is borderline negligent.

Transcoding images is why all old pictures on the web a a blocky mess of unholy JPEG.

There are ways to transcode images in such a way that if they're downloaded and reuploaded to your service you don't lose any further quality in your re-upload.

As someone who shared a good deal of Spore creations over the internet, I disagree.

(The game would generate a "card" with a visual preview, but would stuff the XML encoding of the creation into some PNG metadata field so the image could be dragged onto someone else's game.)

The server is usually processing the images anyway, at the very least to remove EXIF metadata, but also to resize and compress the images for different resolutions.

100% Websites that accept complex media from users really are stupid. It’s bad enough sanitizing other input, but the added costs with transcoding and storing user content, all the meanwhile exposing unnecessary risk to processes. I’d just pipe the media upload to Cloudflare and have them deal with it

Reencoding images doesn’t mean they’re not exploitable anymore.

https://xkcd.com/1683/

The idea here would be that I'm visiting Reddit, someone uploads a malicious WebP, and now my Reddit account is owned, right?

Sites like Reddit load user uploaded content from different domains (redditmedia.com) so you should be safe in this case.

I'm not that familiar with Chrome's process isolation but I think that the renderer process that displays your Reddit.com tab would still render that image, even if it came from a different domain.

Chrome doesn't spin up another process to render the image and then transfer the pixels.

Wouldn’t the exploit code be able to bypass all those cross domain checks? As long as they are running in the same sandbox, right?

It should be noted that some sites (not sure about reddit) will re-encode images in various ways (sometimes to entirely different formats), possibly mitigating this.

Exploits aside, there are quite a few undesirable behaviours you can cause with media, such as the bouncing video file which changes it's height every frame and makes content around it reflow.

TBH I just used Reddit as an example of "site with images", I'm not actually concerned about my Reddit account/ think it'd be a good target.

I'm using lossless webp, it's much more efficient than png

(oops, wrong thread, meant to reply to https://news.ycombinator.com/item?id=37479576 "jpeg is good enough")

This security bug specifically happens in the WebP Lossless decoder ("VP8L").

I lol'd

Looks like you're in a position of not losing anything. ( other than a system and accounts due to a hack )

Is it Web scale?

Are you saying that the renderer can't send information back to the website?

Also, perhaps you turned off JavaScript, and now all of a sudden the website can still execute code?

Reply on news.ycombinator.com