[Syonyk]

Good writeup, thanks for sharing it!

And yet another argument for "You ought to be using Qubes." Random web access needs to be treated as "Genuinely high risk" anymore. A disposable VM with nothing of value in it for "casual web use" seems the right option for exploring the security hostile environment of "the internet."

[chatmasta]

Sure, that might help you on your desktop. But this exploit was only discovered because of a zero-click iOS exploit, where the payload was encoded in an iMessage attachment that opened in Passkit, which rendered the WebP file. (In fact the user didn't even need to "open" the attachment - just receiving the message was sufficient to trigger the exploit.)

So Qubes won't help you everywhere, and the WebP decoder is everywhere.

[cogman10]

Unless you are making a vm per page refresh, I can't really see how a browser in the VM is any safer than a browser outside the VM.

My most valuable stuff (passwords, bank accounts, logins) is accessible from the browser. You'd need to somehow sandbox and frequently destroy/restore the rendering and javascript engine to avoid leaking this information cross site while having a fairly strict firewall between those and the external browser. (IE: cookie/session/password storage).

[Syonyk]

It's not "a browser in a VM."

It's "A range of VMs, with different browsers in them, for different purposes."

My "random web use" browser VMs don't have anything in them - they're ephemeral. If I need a password, I copy it from another VM over. If you escape into that VM, you might be able to grab a password being pasted, but I don't access anything I consider sensitive in them - just random forum accounts, etc. And it's easy enough to spin up other disposable VMs for stuff in Qubes (I actually mostly browse through the Tor network, to add traffic to it).

So, for your use case, you'd have one VM with your "core" stuff - passwords, logged in to webmail, banking. And then you do everything else web related in a different VM.

[cogman10]

Ah, makes sense.

Probably a good solution for the highly technical, not something I could ever propose to my mother.

[halJordan]

I mean your mother is successfully using Apple's highly sophisticated sandboxes and things like authenticated pointers. (sHe's On AnDrOiD)

For Qubes specifically she can understand theres a bank Qube and a Facebook Qube and a nothing-special Qubes and its all color coordinated. She doesn't even need to know they are VMs, they're just color coded windows

[hiatus]

As a qubes user myself, I don't think my mother would be able to perform the initial setup and segregation, not to mention endure the hurdles of copy/paste rules and filesharing across VMs. Oh sure, she could learn another set of copy paste keyboard shortcuts that will end up as another handwritten note on her list of keyboard shortcuts. Not to mention how frequently I'd get called due to slowness as she neglects to close the VMs. And say goodbye to remote support options unless she gives me SSH to dom0 but then why do any of this anyway at that point?

[jwells89]

My bet is that over time most people would slip on the separation and end up with tons of tabs in the wrong containers. The only way it'd work in the long term is if there were some way of automatically taking link clicks in the "wrong" container, thoroughly sanitizing them, and then tossing them over the "right" container but then you're back to risking cross-contamination.

[bennyg]

This is a fun idea, are there any browsers that hide the VM from end users so it looks and feels like a browser instance but is actually a tunnel into a sandboxed VM that’s being painted to?

[Chabsff]

That's kinda-sorta what they all do already. Not full OS-level VM abstraction, but surprisingly close to it. Exploits like this need to be paired with sandbox-escaping in order to do damage beyond the current browsing session (which VMs wouldn't help with in the first place). And the distinction between sandbox-escaping and VM-escaping is rather thin.

[Syonyk]

> And the distinction between sandbox-escaping and VM-escaping is rather thin.

Eh, I think it's a good bit harder to escape a HVM isolated virtual machine than a sandbox. At least, I'm not aware of many cross-Xen VM escapes.

[Chabsff]

Yes, I should have added that I'm referring specifically to the scenario OP is suggesting, which would require a host <-> client IPC channel, opening up the VM to similar attack vectors to a sandbox.

[taway1237]

There's a huge difference. Browser sandboxes are not "real" VMs and share a kernel. And in case of Chromium it's enough to read a few bytes from another process (token) to escape.

[nolist_policy]

Can you elaborate on that? What do tokens have to do with breaking out of a sandbox?

[lmm]

There used to be dozens of them at any given time; maybe they're a bit rarer now that cloud providers have been banging on them for a while.

[tech234a]

This exists as an option for Microsoft Edge on Windows: https://learn.microsoft.com/en-us/deployedge/microsoft-edge-...

[mminer237]

The problem is that browsers are the biggest attack vectors but also the most valuable targets. Getting a user's email password or cookie is probably the most damaging thing they could get unless you're the type to buy cryptocurrencies.

[hiatus]

Not your bank? Email and bank login should be sufficient to change mfa and other settings and lock you out long enough to have forged checks drawn and cashed against your account.

[circuit10]

Browsers already have sandboxes, they're not perfect but neither are VMs, and if you're going for a layer of security through obscurity by having an unusual setup (which is bad on its own but when layered with real security can be fine) then just running Linux is probably enough already

[callalex]

Tools should work for people, not the other way around. The cognitive load of manually managing sandboxes is huge. Instead we could build tools that aren’t fundamentally broken. Memory safety should be formally guaranteed before shipping.