Long Live Sandboxing | Hacker News Reader

Long Live Sandboxing

noncombatant.org

31 pointsmooreds13 comments

I was honestly shocked to see the recent discussions about sandboxing being ineffective due to the escapes, or the statements that this was somehow new, or unexpected, or an open question. Sandbox escapes are as old as sandboxes, they're extremely well understood.

Of course the approach is not a catch-all. A web browser that cares about performance isn't going to want to spawn a process for every bit of JSON it wants to parse, etc. Spectre has made this even worse, since now isolates/VMs are no longer considered boundaries - now every single site has to be isolated from every other (as is addressed in Chris's talk), or you need some sort of heuristic, or whatever.

There's also a massive gap between basic sandboxing and what Chrome does. Seccomp is very hard to maintain, but broader sandboxing like Windows Integrity or DAC on Linux, Apparmor, etc, are quite simple both to implement and to maintain.

What's notable about the ITW attacks is really just that

a) Chrome really owns the market now, and attackers know it's worth the time to exploit

b) Attackers have likely incorporated enough research and tooling to more cost effectively find vulnerabilities in Chrome

c) As the article points out, a lack of memory safety is extremely costly to try to make up for using just one other approach, even a great approach like sandboxing.

From the OS, which provides the sandboxing primitives, up to the broker, and into the renderer, we have memory unsafe languages. Shocker that sandbox escapes occur.

Sucks that Google is so invested in C++, it's obvious that organizational inertia has kept Rust out of Chrome.

Chromium is so incredibly complex, they deal with twenty layers of abstractions and there is concurrency everywhere. Sprinkling a bit of Rust across the code base, and only at the lowest level, will do very little.

The first example I looked up needed a UAF in something that clearly should have been ported from Java to any memory safe language, instead C++ had to be used:

https://theori.io/research/escaping-chrome-sandbox/

Your link is on point, that's exactly the complexity I had in mind and it's everywhere. You can rewrite that component in Rust, you can't add meaningful lifetime information to the pointer that gets passed to it.

You would be unable to write an API like this without unsafe and being encouraged to write new APIs in a way that works in safe rust is an improvement. When I look at chrome/v8 source it is a series of example many distinct APIs each repeating this context problem, probably since this style of API can be the same as in Java, but the Java version is safe thanks to the GC.

(Since their new exploits tend to be in big new APIs that relate to new flags, I think they would be well served by using rust for this splattering of new apis.)

I disagree entirely. Parsers are an excellent plays to start using Rust - this would allow them to move that code back in-process, improving performance, without compromising on security.

It's exactly the sort of thing this post is talking about. I'm not advocating for a wholesale rewrite, that would be ridiculous - but there's very obviously certain areas of attack surface that are harder to sandbox and are great candidates.

Besides, Firefox is even older than Chrome, and at least as complex, and they began the process of replacing core attack surface. Google could put 10x the devs on such a thing.

Meanwhile, on iOS you still can't create subprocesses :-(

Or use custom sandboxing…

Or use any non-Apple browser engine.

“If OS developers give us more of the primitives we want, we’ll jump right on them — as we always have.”

Except they’ve repeatedly ignored previous efforts to upstream sandboxing for FreeBSD.

Ironic that Chrome has an RCE bug without a patch in stable right now and the only protection is the sandbox.

> Our unit of isolation, the process, is expensive in time and space on some (not all) platforms.

Which platforms?

Depends on how many they want to spawn, how often, and for how long. If it's hundreds/thousands short-lived processes in the span of seconds, then Windows is definitely the platform where it's "expensive in time and space".

Reply on news.ycombinator.com