[prev in list] [next in list] [prev in thread] [next in thread]
List: qubes-devel
Subject: 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-devel" group. To unsubscribe from this group and stop receiving emails from \
it, send an email to qubes-devel+unsubscribe@googlegroups.com. To post to this group, \
send email to qubes-devel@googlegroups.com. To view this discussion on the web visit \
https://groups.google.com/d/msgid/qubes-devel/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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic