3 ms·

An attacker would have three primary avenues of attack: 1) Escape the virtual machine sandbox. 2) Denial of service of host resources. 3) Attack network

by grun 13y ago

An attacker would have three primary avenues of attack: 1) Escape the virtual machine sandbox. 2) Denial of service of host resources. 3) Attack network services. For 1), virtual machines provide strong, hardware supported isolation of the host. They can't access the filesystem, resources, or hardware of the host, only their own. For 2), virtual machines also provide strong protection from the denial of service of host resources. Virtual machines can be restricted in memory, CPU, and device use while running. This occurs routinely with virtual machines provisioned on servers. Network services, 3), are the largest attack vector not protected by encapsulation within a virtual machine. One weapon virtual machines do posses, however, is complete control over the virtual NIC. Every packet sent or received can be inspected, modified, or discarded. Arc's network policy is not carved in stone. There is nothing preventing Arc from adopting a same-origin policy, like browsers. Perhaps it will.

rohansingh 13y ago
Another attack vector is to attack the Arc application itself, perhaps with a malformed manifest or something similar. The entire Arc application presents a huge surface area.
AlexanderDhoore 13y ago
Hey, I'm the guy being negative in the other comment. I'm sorry about that. Honest question: Do you really think this could be deployed on a large scale? Without reenacting the security nightmare that is Java Applets? You better be very sure about that...
- ori_b 13y ago
  Java applets aren't isolated from the host OS by the hardware. This is.
  - andreasvc 13y ago
    I don't see the fundamental difference: both run on a virtual machine, and in both cases it is likely that the isolation will be broken by exploits. And just because it's hardware doesn't mean it's less likely to contain bugs...
iuguy 13y ago
> An attacker would have three primary avenues of attack: That's not true. You've identified 3 avenues of attack, there are far more. That's what threat modelling is for. It does not appear that this project has properly considered the threats associated with the attach surface area, but lets look at these three. > For 1), virtual machines provide strong, hardware supported isolation of the host. They can't access the filesystem, resources, or hardware of the host, only their own. Not true. The isolation isn't as strong as you think. Most virtualization software provides avenues to share information between guest and host. Code is still executed on the same hardware. Virtualization isolation is extremely hard to do correctly, and even the pros[1][2], have got it wrong in the past. Even Java's had sandbox issues, as has Google Chrome most recently. It's believed that VirtualBox may have been affected by this[3] bug, which is in Intel's 64-bit CPU architecture, not the product. I say may because it's really hard to confirm without sitting down and writing an actual exploit for the bug. > For 2), virtual machines also provide strong protection from the denial of service of host resources. That's not true. Yesterday I was testing a simple windows fork-bomb type attack (putting %0|%0 in a bat file to be precise) and the VMs were all suffering, as was the host. You can limit available resources in a VM, but that's neither here nor there - what happens if you open multiple VMs? How will the virtualisation react? > Network services, 3), are the largest attack vector not protected by encapsulation within a virtual machine. They're not the largest attack vector by a long way (arbitrary code execution by virtualisation escape is the most significant attack vector), but lets talk about netowrk services. Just because packets could be inspected, modified or discarded doesn't mean they are. If I deploy a malicious VM to your computer and you start it, that means I'm executing the code of my choice in a virtualised environment on your computer on your network. Nothing will change that. You can sandbox parts of it to reduce what can be done to other components and it'll be down to the integrity of the isolation and sandboxing, but unless you start removing instructions, arbitrary code is exactly what my VM executes on your system. Architecturally, it's a bad idea. If you were meant to execute native code on a system from a browser, it'd be supported across multiple browsers and OSes as part of a spec. Even Native Client (NaCl)[4] has it's detractors and has made mistakes (possibly addressed in Pepper), yet seems to most likely do enough to support what this project proposes to do. [1] - http://www.cupfighter.net/index.php/2009/07/blackhat-cloudburst-vmware-guest-to-host-escape/ http://www.cupfighter.net/index.php/2009/07/blackhat-cloudbu... [2] - http://seclists.org/fulldisclosure/2010/Jan/341 http://seclists.org/fulldisclosure/2010/Jan/341 [3] - http://www.kb.cert.org/vuls/id/MAPG-8TVPQL http://www.kb.cert.org/vuls/id/MAPG-8TVPQL [4] - https://en.wikipedia.org/wiki/Google_Native_Client https://en.wikipedia.org/wiki/Google_Native_Client I can understand the dream and the goal but it doesn't stack up. It's dangerous stuff. Stop it.

by grun 13y ago

rohansingh 13y ago

Another attack vector is to attack the Arc application itself, perhaps with a malformed manifest or something similar. The entire Arc application presents a huge surface area.

AlexanderDhoore 13y ago

Hey, I'm the guy being negative in the other comment. I'm sorry about that. Honest question: Do you really think this could be deployed on a large scale? Without reenacting the security nightmare that is Java Applets? You better be very sure about that...

ori_b 13y ago
Java applets aren't isolated from the host OS by the hardware. This is.
- andreasvc 13y ago
  I don't see the fundamental difference: both run on a virtual machine, and in both cases it is likely that the isolation will be broken by exploits. And just because it's hardware doesn't mean it's less likely to contain bugs...

iuguy 13y ago

> An attacker would have three primary avenues of attack: That's not true. You've identified 3 avenues of attack, there are far more. That's what threat modelling is for. It does not appear that this project has properly considered the threats associated with the attach surface area, but lets look at these three. > For 1), virtual machines provide strong, hardware supported isolation of the host. They can't access the filesystem, resources, or hardware of the host, only their own. Not true. The isolation isn't as strong as you think. Most virtualization software provides avenues to share information between guest and host. Code is still executed on the same hardware. Virtualization isolation is extremely hard to do correctly, and even the pros[1][2], have got it wrong in the past. Even Java's had sandbox issues, as has Google Chrome most recently. It's believed that VirtualBox may have been affected by this[3] bug, which is in Intel's 64-bit CPU architecture, not the product. I say may because it's really hard to confirm without sitting down and writing an actual exploit for the bug. > For 2), virtual machines also provide strong protection from the denial of service of host resources. That's not true. Yesterday I was testing a simple windows fork-bomb type attack (putting %0|%0 in a bat file to be precise) and the VMs were all suffering, as was the host. You can limit available resources in a VM, but that's neither here nor there - what happens if you open multiple VMs? How will the virtualisation react? > Network services, 3), are the largest attack vector not protected by encapsulation within a virtual machine. They're not the largest attack vector by a long way (arbitrary code execution by virtualisation escape is the most significant attack vector), but lets talk about netowrk services. Just because packets could be inspected, modified or discarded doesn't mean they are. If I deploy a malicious VM to your computer and you start it, that means I'm executing the code of my choice in a virtualised environment on your computer on your network. Nothing will change that. You can sandbox parts of it to reduce what can be done to other components and it'll be down to the integrity of the isolation and sandboxing, but unless you start removing instructions, arbitrary code is exactly what my VM executes on your system. Architecturally, it's a bad idea. If you were meant to execute native code on a system from a browser, it'd be supported across multiple browsers and OSes as part of a spec. Even Native Client (NaCl)[4] has it's detractors and has made mistakes (possibly addressed in Pepper), yet seems to most likely do enough to support what this project proposes to do. [1] - http://www.cupfighter.net/index.php/2009/07/blackhat-cloudburst-vmware-guest-to-host-escape/ http://www.cupfighter.net/index.php/2009/07/blackhat-cloudbu... [2] - http://seclists.org/fulldisclosure/2010/Jan/341 http://seclists.org/fulldisclosure/2010/Jan/341 [3] - http://www.kb.cert.org/vuls/id/MAPG-8TVPQL http://www.kb.cert.org/vuls/id/MAPG-8TVPQL [4] - https://en.wikipedia.org/wiki/Google_Native_Client https://en.wikipedia.org/wiki/Google_Native_Client I can understand the dream and the goal but it doesn't stack up. It's dangerous stuff. Stop it.