[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qubes-users
Subject:    [qubes-users] Re: [qubes-devel] Re: Qubes Security Bulletin #23
From:       Joanna Rutkowska <joanna () invisiblethingslab ! com>
Date:       2015-12-22 0:05:16
Message-ID: 20151222000516.GC10649 () work-mutt
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Dec 21, 2015 at 09:56:42AM -0800, Eric Shelton wrote:
> On Monday, December 21, 2015 at 12:28:24 PM UTC-5, Vít Šesták wrote:
> > 
> > On Monday, December 21, 2015 at 6:09:53 PM UTC+1, Eric Shelton wrote:
> > > 
> > > I do not think that is correct.  Looking at lines 78-108 of the QSB, the 
> > > characteristic that defines what you call a "traditional Xen deployment" 
> > > does not have anything to do with using an IOMMU, but instead whether a 
> > > backend is located in dom0 or in a "driver domain."
> > > 
> > Sure, even without IOMMU, Qubes is not the "traditional Xen deployment" 
> > (TXD). But it is much more similar to the TXD, because all domains with a 
> > PCI device have access to whole RAM through DMA, so they are effectively a 
> > part of TCB. In such cases, the attack gives attacker nothing previously 
> > not owned on any non-IOMMU system.
> > 
> > 
> > > In contrast, Qubes has at least the net backend in NetVM, as well as 
> > > ProxyVM as you noted.  Plus, if you set up a USBVM, sharing a USB flash 
> > > drive or such causes the USBVM to act as a block backend as well.
> > > 
> > That's true. However, if NetVM or USBVM is compromised on a non-IOMMU, 
> > then they can perform the DMA attack. It depends if ProxyVMs and 
> > FirewallVMs are to be considered as a significant additional risk.
> > 
> 
> Both of the above comments seem to be saying: "if you do not have an IOMMU, 
> you're already burned, because you are open to DMA attacks."   I disagree 
> with the situation being quite that binary, and it assumes a DMA attack is 
> easy to come by.  They are two distinct attack vectors.  I suspect that QSB 
> #23 is the more powerful of the two for an attacker, because it is purely a 
> software issue for which an exploit might be engineered to work against 
> 100% of vulnerable (meaning unpatched) systems, while a DMA-based attack 
> would likely be limited to targets with particular hardware.  That does not 
> mean that a hardware-based attack cannot be devastating - for example, a 
> wireless adapter that can be subverted by "the packet of doom" - but such 
> attacks are a separate issue, and there is a security benefit in fully 
> addressing QSB #23 even on an IOMMU-less system.
> 

DMA attacks are always possible (as in: no h/w or other vulnerability required)
from IOMMU-non-protected domains and are actually easy to implement. See e.g.:
http://invisiblethingslab.com/resources/bh08/part1.pdf

joanna.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJWeJO8AAoJEDOT2L8N3GcY2cUP/iTVgooXGjBh0bDV77l1OX2M
MpdCWSK2dFhiiJwPybcah834cP0Jz4hmPA0KcRCjsoAB5ZWFbkkVXnCBAOVODNbm
1MoboUsBUT3cFs7hmgoduIY3BPbGJIDhdazlFYYF5TG0P4VQIh8HIevStX59MBuF
zR+z7GbbYA3WJzfKHjzxfeB7t6u2xvvrxf3EJl5GPuRu2f9RucqceN53NUyzOBjH
+L/C074cHkfaTrMfaYHbmJynJQKbW09AyoB/WQHsTblsrPy88cdYWIoFx0f1lcaP
ND3/E+UluGOGT5b8N/KVXk9qohtPM6zHgaqOi2HJ0I6paM42xcHjPAnX7sqE0aYC
KDRy+vsBGLXPgiA44wpNNtrc4UxCqBcRyDN5emVqz1lY1luTNY8SfYVmdSi0byXd
+xD5pgPq7fzFOrx5+/oyleatt9DfBsLUhq7y/sC30aak/s6T+bJUwRczfv4gbu7z
6YtgCGegvHKsTeB5RD/RIOoN3OTIGflKDLgWom5mo7eTGsdmKfpe8NNf2KM7PruP
Tl31e662pJg5Y7Oo/WI3sJni/EMGOW2JeU2wA/4uTFQsErslhl9fMuD8VC4hNDfV
q3auKu30bR2dwkGBbvmoYXaQ4TVCp/ni+6mMGqZj8t8ENIbnO2RtuFixbSQ/FDJC
nsyK4wO9qtPnlcz9m51G
=0oPV
-----END PGP SIGNATURE-----

-- 
You received this message because you are subscribed to the Google Groups \
"qubes-users" group. To unsubscribe from this group and stop receiving emails from \
it, send an email to qubes-users+unsubscribe@googlegroups.com. To post to this group, \
send email to qubes-users@googlegroups.com. To view this discussion on the web visit \
https://groups.google.com/d/msgid/qubes-users/20151222000516.GC10649%40work-mutt. For \
more options, visit https://groups.google.com/d/optout.


[prev in list] [next in list] [prev in thread] [next in thread]