[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] [qubes-devel] please look at Comparison of Whonix, Tails, TBB and Qubes OS TorVM
> On Mon, Feb 11, 2013 at 1:12 PM, Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx> 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 :)
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk