Hacker News Reader

Comment by dspillett | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com