Silk Road forums

Discussion => Security => Topic started by: BearedF on October 06, 2012, 11:40 pm

Title: VSentry - New virtualization idea/software
Post by: BearedF on October 06, 2012, 11:40 pm
From Xen people.

http://www.theregister.co.uk/2012/09/19/bromium_vsentry_security_launch/
http://www.brianmadden.com/blogs/guestbloggers/archive/2012/09/20/guest-blog-from-simon-crosby-explaining-what-bromium-is-and-how-it-works.aspx

Any way to use this in our advantage ?
Title: Re: VSentry - New virtualization idea/software
Post by: kmfkewm on October 07, 2012, 09:27 am
It sounds a lot like Qubes, which also uses Xen and seems to do the same thing, but is free. You can certainly use isolation techniques to your advantage. Qubes even has secure copy paste between virtual machines, so you could implement a virtualization based 'air gap' with it by running GPG in one VM and firefox in another. Then you could copy ciphertexts from the GPG vm to the firefox VM. That way if firefox is pwnt the attacker will have more trouble to get to your plaintexts. It is also the easiest way to get x level isolation between apps, the lack of which is a truly enormous attack vector that all current window managers have. You could have it automatically open .pdf files in virtual machines that don't have access to the internet, so you would worry less about opening pdfs or docs or anything that phones home. You could make temporary sandboxes to run applications in pretty quickly. You could have Tor running in a different vm than firefox or pidgin, so even if those applications are pwnt the attacker can not easily deanonymize you. You can also isolate an attackers ability to spread through your system, if you do sensitive things in pidgin and firefox the compromise of one will not essentially ensure the compromise of the other. Virtualization based security has its own andvantages and disadvantages, it seems that paravirtualization solutions like xen offer the best ratioed trade off between security of applications/environments and isolation between applications/environments, but they are not without some serious drawbacks. For example currently xen does not support ASLR so you lose that security advantage, it also is not as secure to use virtual machines as it is to run directly on hardware so it could additionally hurt your security some here. Virtualization is from the isolation school of computer security, and isolation is widely recognized as a legitimate way of obtaining security, although some people like it a lot more than others and it isn't without its critics. 
Title: Re: VSentry - New virtualization idea/software
Post by: Xe on October 07, 2012, 01:44 pm

Virtualization is the way of life.. Essential.. Thank you..
Title: Re: VSentry - New virtualization idea/software
Post by: BearedF on October 07, 2012, 06:29 pm
Ex Quebes developer is part of the Bromium team.

Biggest advantage of this solution is Windows support. Qubes will have that somewhere in 2013.

By Joanna

How is Qubes different than Bromium's “micro virtualization” solution?

Many people asked recently about the Bromium's upcoming product and how it differs from Qubes OS. Unfortunately there are few public information available on this product – essentially there is one not-very-technical whitepaper and there are Ian Pratt's presentation slides from the recent XenSummit about u-Xen, apparently a hypervisor that is to be ultimately used in their upcoming product.

The whitepaper suggests that Bromium is based on a hosted (type II) hypervisor running within a normal Window OS, and that this hypervisor is used to spawn a new “micro VM” for each new “task”, where apparently the task might be something as granular as opening a new tab in a Web browser, which makes it somehow similar to Google Chrome's approach. Clearly, the Bromium's main goal seem to be to automate the process of creating separation domains, which is in contrast with what we do on Qubes OS, where the user is required to define the domains explicitly.

The Pratt's slides provide also some technical insight into how Bromium intends to secure their hypervisor. As just discussed above, a hosted hypervisor must normally trust the hosting OS, in this case Windows, which, for obvious reasons, is not a good idea from the security standpoint. Pratt, however, clearly states that “host (...) can not interfere with the privacy or integrity of the hypervisor or other guests” (slide #8). This is a strong statement, so let's take a closer look at their approach to this problem.

The Bromium's idea of how to make their hypervisor (and the VMs) protected from a potentially malicious host OS is not really breakthrough: the slides suggest to “deprivilege the host into a VT-container” (I think the verb to bluepill is now an accepted term for such action ;), and to remove the host's access to the hypervisor pages (via EPT), as well as protect DMA access from devices via VT-d, plus to make this all sensible, use DRTM scheme such as Intel TXT, to load such a hypervisor from within a potentially untrusted OS.

So, what's wrong with the idea of a load-on-the-fly-secure-VMM-system? Isn't Ian Pratt correct that one could protect its memory and execution from the interference of the host? Actually that is possible – Intel TXT, VT-x, VT-d, and EPT give us means to achieve that (although there are a number of catches here). But he's missing one important point: it's the untrusted OS that still owns and manages the input devices (e.g. via USB stacks and drivers) and, most importantly, the output (via the GUI subsystem and drivers). Ensuring that the host OS cannot interfere (e.g. sniff the screen of trusted applications) might be very difficult, or even impossible, in practice.

If I ever was to break the security of such a system, I would just follow the simple way:
1) Infect the host e.g. via one of the many USB attacks (remember they cannot have sandboxed USB driver domain, as they have only a type II hosted hypervisor),
2) Hook somewhere into the GUI subsystem and keep recoding all the interesting data from the screen...
... or something like that ;)

There are also many other things that needs to be answered and which the publicly available documents are silent about, such as e.g. how does the system handle installation of new applications? How is clipboard and file exchange between (micro)VMs handled? How large are the interfaces exposed to each (micro)VM? For now, without a solid documentation available, and without any code to play with, it is just another vaporware for me. (Interestingly there seem to be Bromium's Beta program, which however doesn't seem to be working, at least not for me -- I tried to signup twice, but never got any confirmation or response...?)
Title: Re: VSentry - New virtualization idea/software
Post by: Miss Sixty on October 11, 2012, 11:49 am
Ex Quebes developer is part of the Bromium team.

Biggest advantage of this solution is Windows support. Qubes will have that somewhere in 2013.

By Joanna

How is Qubes different than Bromium's “micro virtualization” solution?

Many people asked recently about the Bromium's upcoming product and how it differs from Qubes OS. Unfortunately there are few public information available on this product – essentially there is one not-very-technical whitepaper and there are Ian Pratt's presentation slides from the recent XenSummit about u-Xen, apparently a hypervisor that is to be ultimately used in their upcoming product.

The whitepaper suggests that Bromium is based on a hosted (type II) hypervisor running within a normal Window OS, and that this hypervisor is used to spawn a new “micro VM” for each new “task”, where apparently the task might be something as granular as opening a new tab in a Web browser, which makes it somehow similar to Google Chrome's approach. Clearly, the Bromium's main goal seem to be to automate the process of creating separation domains, which is in contrast with what we do on Qubes OS, where the user is required to define the domains explicitly.

The Pratt's slides provide also some technical insight into how Bromium intends to secure their hypervisor. As just discussed above, a hosted hypervisor must normally trust the hosting OS, in this case Windows, which, for obvious reasons, is not a good idea from the security standpoint. Pratt, however, clearly states that “host (...) can not interfere with the privacy or integrity of the hypervisor or other guests” (slide #8). This is a strong statement, so let's take a closer look at their approach to this problem.

The Bromium's idea of how to make their hypervisor (and the VMs) protected from a potentially malicious host OS is not really breakthrough: the slides suggest to “deprivilege the host into a VT-container” (I think the verb to bluepill is now an accepted term for such action ;), and to remove the host's access to the hypervisor pages (via EPT), as well as protect DMA access from devices via VT-d, plus to make this all sensible, use DRTM scheme such as Intel TXT, to load such a hypervisor from within a potentially untrusted OS.

So, what's wrong with the idea of a load-on-the-fly-secure-VMM-system? Isn't Ian Pratt correct that one could protect its memory and execution from the interference of the host? Actually that is possible – Intel TXT, VT-x, VT-d, and EPT give us means to achieve that (although there are a number of catches here). But he's missing one important point: it's the untrusted OS that still owns and manages the input devices (e.g. via USB stacks and drivers) and, most importantly, the output (via the GUI subsystem and drivers). Ensuring that the host OS cannot interfere (e.g. sniff the screen of trusted applications) might be very difficult, or even impossible, in practice.

If I ever was to break the security of such a system, I would just follow the simple way:
1) Infect the host e.g. via one of the many USB attacks (remember they cannot have sandboxed USB driver domain, as they have only a type II hosted hypervisor),
2) Hook somewhere into the GUI subsystem and keep recoding all the interesting data from the screen...
... or something like that ;)

There are also many other things that needs to be answered and which the publicly available documents are silent about, such as e.g. how does the system handle installation of new applications? How is clipboard and file exchange between (micro)VMs handled? How large are the interfaces exposed to each (micro)VM? For now, without a solid documentation available, and without any code to play with, it is just another vaporware for me. (Interestingly there seem to be Bromium's Beta program, which however doesn't seem to be working, at least not for me -- I tried to signup twice, but never got any confirmation or response...?)

It is aimed at Win7 64 Vt-d systems not Windows in general.