6 ms·

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

by Syonyk 3y ago

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

deleted 3y ago
[deleted]
bennyg 3y ago
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?
- mminer237 3y ago
  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 3y ago
    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.
- Chabsff 3y ago
  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 3y ago
    > 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.
    - lmm 3y ago
      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.
    - taway1237 3y ago
      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 3y ago
        Can you elaborate on that? What do tokens have to do with breaking out of a sandbox?
    - Chabsff 3y ago
      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.
- tech234a 3y ago
  This exists as an option for Microsoft Edge on Windows: https://learn.microsoft.com/en-us/deployedge/microsoft-edge-security-windows-defender-application-guard https://learn.microsoft.com/en-us/deployedge/microsoft-edge-...
cogman10 3y ago
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 3y ago
  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 3y ago
    Ah, makes sense. Probably a good solution for the highly technical, not something I could ever propose to my mother.
    - halJordan 3y ago
      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 3y ago
circuit10 3y ago
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
chatmasta 3y ago
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.
callalex 3y ago
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.

by Syonyk 3y ago

deleted 3y ago

[deleted]

bennyg 3y ago

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?

mminer237 3y ago
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 3y ago
  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.
Chabsff 3y ago
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 3y ago
  > 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.
  - lmm 3y ago
    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.
  - taway1237 3y ago
    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 3y ago
      Can you elaborate on that? What do tokens have to do with breaking out of a sandbox?
  - Chabsff 3y ago
    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.
tech234a 3y ago
This exists as an option for Microsoft Edge on Windows: https://learn.microsoft.com/en-us/deployedge/microsoft-edge-security-windows-defender-application-guard https://learn.microsoft.com/en-us/deployedge/microsoft-edge-...

cogman10 3y ago

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 3y ago
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 3y ago
  Ah, makes sense. Probably a good solution for the highly technical, not something I could ever propose to my mother.
  - halJordan 3y ago
    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 3y ago

circuit10 3y ago

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

chatmasta 3y ago

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.

callalex 3y ago

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.