Qubes Security Bulletin #23

[Joanna Rutkowska]

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

Dear Qubes users,

We have just released a new Qubes Security Bulletin (QSB #23):

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-023-2015.txt

Regards,
joanna.

- --
The Qubes Security Team
https://qubes-os.org/doc/SecurityPage/
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJWcqg1AAoJEDOT2L8N3GcYzT0P/RnkctuokzCN5WMy4eVn7UzK
ZfOr5LwFHBkGLGNzG+LQfg4hb4p8aJ3KLPkIJUWgDs1pcnXCjb1YstXzSU0ViOy6
6rXcbv6SPQr/izsylsZKJcx8XnQGhDKk+qHsRvfq4KNICNNM1WN0CCzRX8BHH5CI
HLyEoC0carWXtZFfue3OBiz42dgABmWnkJFfYhFf68knWenUWga4FTJ5KhsrqK+k
f/XSzAETtNcvk/6qlj3HBsJJ26v9t3TdOisLE4VNNUx4CSwqhZoEhYZKx37cYtJf
BNv2AHfs6xzHP82/6BohNbJP7asZcipFl5i5aGoY/6w/wYFGupRQf2cRXX07+HBQ
WG42F5hLO4YTSzKk7yK9JmbrGX/aCnLVW92wVL9XEgVGkROdY0p2hoJLJrMKIUO/
WP/tx+pHvcILbPspM1X/Qut2+L7Ld33WznHDIX1EQyS8DUQ89hVOW9n9wn9uM1l1
wZ97Ph6Z8odboKW1C9FLBMOb6Z8F3qucVGCdAwoHZncEnmEklCTZ9izkq9KDFvHZ
LILidncgBWoiSFo+X4q4fBqmmIPs6ZXRCvBRy9Hq30jcqLaO3mEH0/eqdDdsRabb
xv1W9lOFFQDxR5H78u6UyTRAvCN+1a2dvZXIMN7XaAsDeQSXBwUgK87hfF+jOdvv
BZbjliwFNmikXlgJc5Zw
=2WUp
-----END PGP SIGNATURE-----

[Vít Šesták]

The QSB is very detailed, but I am not sure if I have correctly extracted the conclusion: It potentially allows attack from NetVM (or maybe even FirewallVM or ProxyVM?) to some AppVM. Is that correct?

Regards,
Vít Šesták 'v6ak'

[Marek Marczykowski-Górecki]

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

On Sat, Dec 19, 2015 at 04:57:04AM -0800, Vít Šesták wrote:
> The QSB is very detailed, but I am not sure if I have correctly extracted
> the conclusion: It potentially allows attack from NetVM (or maybe even
> FirewallVM or ProxyVM?) to some AppVM. Is that correct?

Yes. And also very theoretically also from block frontend to backend (so from
VM to dom0).

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWdW4gAAoJENuP0xzK19cshREH/RnjuPcJsj8aN3KaBXOXo9Ho
dRx+D5HY69dzoT7Xa52LYxAUxRdrwrlOwQfiNXOZfCXP22b4bP1hoZ8TuU5KxGTH
P2Zk6iVmIlUl4NwvYlVMtSe7oy9Mew9OUfcyLt45HfLnTHNdP/A8HDJFAfyzReDa
7XtpG6LoASIQn0KUhW2C4WvjsQ1P7QD/OdUgPdTV2X5IGAFNgx+PsaAq/7o47/fk
pWLhMRdnjpGkLtEDt8oi6yHycbr6GB7ysctlTHo3vsQ7yxeyNsMCyFSiCMKCzz0+
Jy+J0lzLv+yJy88O0PUhGqWVXsLRBPyHXPsxli8/fHcRXuxFDCyztHNcxQkF5vk=
=AMaS
-----END PGP SIGNATURE-----

[donoban]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I want to try security-testing updates. I did:

#sudo qubes-dom0-update --enablerepos=security-testing

and get:

Error getting repository data for security-testing,
repository not found.

Any idea?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJWdafeAAoJEBQTENjj7QilsNIQAJkg7ttdROX1uUQCunalAPxA
e4vvFR3FN0Bw5qRnyIqMZ38mvxp3ePBcjKm40p2TyBpAianZ76zxQCDe0Du0pPZm
zEPxpR5w03UhlLO6zoJArbGSGnKYpe80F53csExiC494p1b65Wf6wfL6DcmQAI4J
YBdq3Gj+ZZuhCOIJSM7CC/LjZNpKOrNUCwKYvD0KL+CS84vhr+Mlv/uIrmXXtmgH
4rnNT5MROTTdUjjcDX0lUyW7G5qaQafSrHRv/GLlux+1+vII2nQSxR5a2hLm1NvJ
sGP9r0fr2whR/ZfhAfv75IQL15usIP8D2BIcgFI6OkgI2fUKy5fRM7us0QG+E/q0
Fd2MyxagOhpk9cB2hu2xUAg+S0MZ+ciS4QmlO5OByBfSSi6hILS/SsiW8SgusmOK
7T3vnxZja7Bia0ePNuJIYiGF/hVb6zYlOhAsBht3X06kngvXuTiUGQtO6GxmNkKj
8FlGpWNaBkVOmM39MRqM1tdEYOaDmA/60cueaV/LyJ80sepKUUEvCxPD0p5XHWtj
p9bOj4/xpv/Nlm0vkr1rPYdvxoQIAop38/pEuDea59zTOZY4CeKP6+lx/SJdclwC
4djDszm3vPahFxDCKuRDa3BKx8YAJPlhDBh5R1S0TlZ/GleeYr2c0iyTcP9nIjG1
/Ypjm0YrVqd2uJOEcypN
=WJk6
-----END PGP SIGNATURE-----

[nobody]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 12/19/2015 01:54 PM, donoban wrote:
> I want to try security-testing updates. I did:
>
> #sudo qubes-dom0-update --enablerepos=security-testing
>
> and get:
>
> Error getting repository data for security-testing, repository not
> found.
>
> Any idea?
>

use --enablerepo=qubes-dom0-security-testing
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWda9nAAoJECVOC2Tp0QhTn1cP/A/GWvFGYhJcZ5QFxqZA9Vot
a52+iQMKoNR2VSyd0udtFzuggAKLoQAnDU9D9zX97X26p/DGKZiAN0xnVybn16EU
K0DL4ePYMorWws593kxFfDZltbRzjm+72tBYLj64DPqsiiispEEahMiYetDNrY+w
w72MP3LkYfpjUwPfO6EgdzQ5zWBiBumH6kQVYZqmzH/CQ1FNF89vINlDNc5CZcLk
xjLoNj+7U0Wk94TgN/in8rtWNW9qTP8ZOG4q0CHW4RBA9JVw8xp9P1/aNAr06JPj
ZpjsmXNvoAo/AX6CK9rC9R4VW5VG5qD/K/x78Mixm/sds1HTivnJW5TIqmO6ptUD
jk5T1TQQxGHJ215d6Cqhur4TsK3s89CtarUhHbYUDmHGoOLG2c35RmKbjxqqPWM3
ij8OudQ95cmTUIx7/si0qcf1s1RJ68MY2RrZQ/NE7FLBrwyiAfubM5XQDhBscyUJ
aCmW9izDhSSrVI10sE16mY1RqMgiFGvPEjbSP0Og9osGJBBfy/KXI9sOKXVL7zBC
diMzWWN8mDwvBYaEW4CUK53b3BJ5rR6okFgdnxz0mU2XEc6fCFZotL0orsO83UQ8
pxjv359Cu3tET+ABmBVPmGqo3xCIO7ECN6Egd+B4HRKoJlRDl2m4YR2IPbELtgAy
ze0JepfINdvvO8zM/FxF
=D9v6
-----END PGP SIGNATURE-----

[Vít Šesták]

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.

Regards,
Vít Šesták 'v6ak'

[Eric Shelton]

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

[Eric Shelton]

On Thursday, December 17, 2015 at 7:19:12 AM UTC-5, joanna wrote:

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

Dear Qubes users,

We have just released a new Qubes Security Bulletin (QSB #23):

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-023-2015.txt

Regards,
joanna.

- --
The Qubes Security Team
https://qubes-os.org/doc/SecurityPage/

 

Should the Windows PV drivers included in the Qubes Windows Tools also be updated in view of QSB #23?

Eric

[Vít Šesták]

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.

Also, the QSB notes an example where an AppVM hosts an ISO for another domain.

Maybe this could have some impact, not sure. However, I am not sure if the block device sharing allows such attack and what direction it would work in. If host can attack the guest, but not vice versa, I usually don't care, because I usually run installer from such device, implying some trust…

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

This is what I am not sure about. Maybe such attack would have to be slightly adapted for some type of the PCI device. But if you have a well-known device…

Regards,
Vít Šesták 'v6ak'

[Eric Shelton]

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.

Eric

[marmarek]

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

Good point... Version 3.0.4 uploaded to both current-testing and
security-testing repositories.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWeHn9AAoJENuP0xzK19csgkoH/1e1teI59UhdIU4FsLkVXIoP
knt/eku025QUY6Gyai4RUX0B7oE0Oiym7ieoj5HPxuuIGDA8pri+ILBKXSGk8Fel
KfVOCQvoN9SykQfC4f1GYNo5nSZ5CNBFPZKyJa3r1/hUuyd7ipWnXvKRXvoSdiuB
ocshBKuztXMdkGdScsyZbbPxJctB8fBfeKfLASZAEdz5lrj1HXLomI9U1f0sWK9h
ZXQyvBF2KuGvHP1S9ZfaSY9V57gV5bac3RnCg08s57VqfFFw05aEK+LDwvspYFYT
tNd6HSz9U47vg2w0xlnH2qdCF12PR47KfcRgbqjAudA9qI/K5U1DUlJdkNh8zFk=
=w5nE
-----END PGP SIGNATURE-----

[Joanna Rutkowska]

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

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-----

[Vít Šesták]

On Monday, December 21, 2015 at 6:56:42 PM UTC+1, Eric Shelton wrote:

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.

OK, that's true. For targeted attacks by powerful-enough attackers, it does not matter. For mass attacks or attack by not so powerful attacker, using long time known DMA attacks (that are not patchable on some systems) would be probably more economical than using an exploit known for short time and likely to be patched very soon.

Regards,
Vít Šesták 'v6ak'