On Mon, Feb 11, 2013 at 1:12 PM, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote:
1) You mention "vm exploit" in a few places. While I understand your intention, I think it's not quite fair to compare e.g. a vm exploit against Virtual Box with a vm exploit against Qubes. Even comparing Virtual Box against Xen would be unfair, and in Qubes we have additionally put some more work into further (comparing to Xen) minimizing possibility of such attacks, e.g. by moving network backends to untrusted netvm by default, by using explicit kernels for PV domains, by using our custom GUI virtualization, by refactoring/hardening HVM support, and ...
On Wed, Feb 20, 2013 at 5:39 PM, adrelanos <adrelanos@riseup.net> wrote:
I see. Any suggestion how I could highlight that?
Qubes is built with security in mind and a clear intent to minimize attacks surface. this is akin to the proactive defense grsecurity and a hardened distro provides against a generic distribution. compare the opposite approach of VMWare or VirtualBox which focus on features and low level accelerations (kernel driver for network, graphics, USB, acceleration, other extensions) without thought to the added risk these less then hardened components expose the host operating systems and other guests to. for example, but not limited to, networking passive and active attacks on physical and virtual endpoints, local and host privilege escalations, driver level privilege escalations, and many other serious vulnerabilities Qubes prevents outright by design and explicit intent.
[re cold boot attacks] but they are quite active and it's reasonable, that they will succeed. I can only give you a bunch of links. Should there be still questions, I recommend to sign up for the tails-dev mailing lists. They are friendly and if you read their pages and there are still questions, I am sure they answer very detailed. Even if there are no questions, I am sure they enjoy your comments.
https://tails.boum.org/doc/advanced_topics/cold_boot_attacks/index.en.html https://tails.boum.org/contribute/design/memory_erasure/ https://tails.boum.org/bugs/sdmem_does_not_clear_all_memory/ https://tails.boum.org/todo/protect_against_external_bus_memory_forensics/ https://tails.boum.org/todo/erase_memory_when_the_USB_stick_is_removed/ https://tails.boum.org/todo/erase_video_memory_on_shutdown/ https://tails.boum.org/todo/hugetlb_mem_wipe/ ...
all of these protections require zeroization to be performed before physical access; an interesting HCI design detail itself... (at DEF CON there are the usual hack the software attack challenges, and non computing seal and lock based physical attack challenges, but i have not yet seen a hack the running system cold boot attack challenge - perhaps because a real attack would likely be destructive to some or most of the hardware to be tested. i'd still be game for mobile and workstation challenges if anyone else is interested :)