[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: Eric Shelton <knockknock () gmail ! com>
Date: 2015-12-21 17:09:52
Message-ID: 2906297b-5c74-458b-b37a-be7159349d58 () googlegroups ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sunday, December 20, 2015 at 5:24:24 PM UTC-5, VÃt Å esták wrote:
>
> Thank you, Marek. So, I've concluded that the vulnerability has rather
> minimal impact to non-IOMMU (non-VT-d) machines:
>
> * On those machines, you already trust NetVMs.
> * Of course, the vulnerability could be also abused from a ProxyVM (or
> FirewallVM, which is a special type of ProxyVM). This is the little
> additional risk.
> * As you note, there is a very theoretical ability to attack dom0 from
> domUs. (Maybe they are limited just to ProxyVMs, I am not sure.) For this
> reason, I've installed the updates in dom0.
>
> Essentially, non-IOMMU setups are more like the traditional Xen
> deployments mentioned in the QSB.
>
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." In a more typical
(non-Qubes) Xen deployment, all of the block and net backends are in dom0.
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. Also,
the QSB notes an example where an AppVM hosts an ISO for another domain.
Another vulnerable frontend/backend combination is provided by
xen-pciback, which comes up with IOMMU use - but exploits via the network
and storage frontends/backends mentioned above remain even when the IOMMU
is not involved.
Thus, in the event that one of these backend domains (NetVM, ProxyVM, or
USBVM) is compromised, an attacker could stage a software-only attack
against other domains via the ring buffers in Xen shared memory used for
frontend/backend communication. As noted in the QSB, the original defect
could be exploited to obtain arbitrary code execution in the targeted
domain. In general, those other domains are the various AppVMs. dom0 is
not at much risk, but mostly because it does not make use of a network
frontend, and (in the present Qubes architecture - the original proposed
architecture had a separate StorageVM) operates its own storage directly
(and serves as a backend for the other VMs). However, if you have dom0
make use of a block device provided by USBVM, then an unpatched dom0 would
be at risk.
The IOMMU protects domains from an entirely different class of attacks:
DMA-based attacks where an attacker persuades a PCI/PCIE device to DMA data
to a destination that belongs to a different domain than the one hosting
the device. Network adapters - particularly since they are ubiquitous,
often have their own firmware (that might be exploited or rewritten), and
PCI option ROMs - are a significant example of devices that can be hijacked
to perform such attacks; thus, ideally they are in a separate
IOMMU-isolated domain. However, even on a system without an IOMMU, I would
not say that we "already trust NetVMs," as there is still significant
isolation provided by having it in a separate domain - isolation that would
be weakened by the defect described in QSB #23.
Eric
--
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/2906297b-5c74-458b-b37a-be7159349d58%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Attachment #5 (text/html)]
<div dir="ltr">On Sunday, December 20, 2015 at 5:24:24 PM UTC-5, VÃt Å esták \
wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: \
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir="ltr">Thank you, \
Marek. So, I've concluded that the vulnerability has rather minimal impact to \
non-IOMMU (non-VT-d) machines:<br><br>* On those machines, you already trust \
NetVMs.<br>* Of course, the vulnerability could be also abused from a ProxyVM (or \
FirewallVM, which is a special type of ProxyVM). This is the little additional \
risk.<br>* As you note, there is a very theoretical ability to attack dom0 from \
domUs. (Maybe they are limited just to ProxyVMs, I am not sure.) For this reason, \
I've installed the updates in dom0.<br><br>Essentially, non-IOMMU setups are more \
like the traditional Xen deployments mentioned in the \
QSB.</div></blockquote><div><br></div><div>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." In a more typical (non-Qubes) Xen deployment, all of the block and \
net backends are in dom0. 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. Also, the QSB \
notes an example where an AppVM hosts an ISO for another domain. Another vulnerable \
frontend/backend combination is provided by xen-pciback, which comes up with IOMMU \
use - but exploits via the network and storage frontends/backends mentioned above \
remain even when the IOMMU is not involved. </div><div><br></div><div>Thus, in the \
event that one of these backend domains (NetVM, ProxyVM, or USBVM) is compromised, an \
attacker could stage a software-only attack against other domains via the ring \
buffers in Xen shared memory used for frontend/backend communication. As noted in \
the QSB, the original defect could be exploited to obtain arbitrary code execution in \
the targeted domain. In general, those other domains are the various AppVMs. dom0 \
is not at much risk, but mostly because it does not make use of a network frontend, \
and (in the present Qubes architecture - the original proposed architecture had a \
separate StorageVM) operates its own storage directly (and serves as a backend for \
the other VMs). However, if you have dom0 make use of a block device provided by \
USBVM, then an unpatched dom0 would be at risk.</div><div><br></div><div>The IOMMU \
protects domains from an entirely different class of attacks: DMA-based attacks where \
an attacker persuades a PCI/PCIE device to DMA data to a destination that belongs to \
a different domain than the one hosting the device. Network adapters - particularly \
since they are ubiquitous, often have their own firmware (that might be exploited or \
rewritten), and PCI option ROMs - are a significant example of devices that can be \
hijacked to perform such attacks; thus, ideally they are in a separate IOMMU-isolated \
domain. However, even on a system without an IOMMU, I would not say that we \
"already trust NetVMs," as there is still significant isolation provided by \
having it in a separate domain - isolation that would be weakened by the defect \
described in QSB #23.</div><div><br></div><div>Eric</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups \
"qubes-devel" group.<br /> To unsubscribe from this group and stop \
receiving emails from it, send an email to <a \
href="mailto:qubes-devel+unsubscribe@googlegroups.com">qubes-devel+unsubscribe@googlegroups.com</a>.<br \
/> To post to this group, send email to <a \
href="mailto:qubes-devel@googlegroups.com">qubes-devel@googlegroups.com</a>.<br /> To \
view this discussion on the web visit <a \
href="https://groups.google.com/d/msgid/qubes-devel/2906297b-5c74-458b-b37a-be7159349d \
58%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/ \
msgid/qubes-devel/2906297b-5c74-458b-b37a-be7159349d58%40googlegroups.com</a>.<br /> \
For more options, visit <a \
href="https://groups.google.com/d/optout">https://groups.google.com/d/optout</a>.<br \
/>
------=_Part_309_653903038.1450717792904--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic