Thunderbolt port attack

[bradbury9]

Looks like a new evil maid attack [1][2] that takes advantage of the thunderbolt port is on the wild.

I do recall Qubes OS had anti evil maid features. I wonder, are Qubes OS protected against this new attack?

[1]: https://www.schneier.com/blog/archives/2020/05/attack_against_2.html

[2]: https://www.wired.com/story/thunderspy-thunderbolt-evil-maid-hacking/

[Brendan Hoar]

In the vernacular, I'm talking out of my behind here, armchair philosophizing, etc...but, well, I find the topic interesting... :)

My gut says that this is a in a class of known vulnerability channels. That is, those of unsigned and/or unchecked firmware on the motherboard. Both in the general case and specifically for Qubes.

So, as always: there's the general caveat that if your system's firmware (including both "bios/uefi" and the firmware for integrated peripherals) have been compromised, and you have certain very specific threat models, you're hosed. AEM/Safeboot can only mitigate some of that: if a particular component's firmware isn't measured, then that's an open door.

That being said, within Qubes I believe this particular attack is somewhat mitigated by the combination of IOMMU, and the Qubes-specific disabling of "hotplug" for pcie devices, including thunderbolt.

IOMMU/hotplug restrictions prevent newly arrived PCIe devices from accessing, via DMA, the memory spaces of dom0/domU. If you're running newer dom0 kernels there are additional backstops as well in-kernel (but I am not familiar with them), though they may be the belt to the suspenders under Qubes.

So...I don't imagine the tried-and-true "screen unlock hack via DMA to bypass code path or variable setting" will work, but...outside the scope of this hack, there may already be other ways to do things like extract encryption keys from a live system if seized live (e.g. freeze memory dimm/move quickly to another powered custom device/dump RAM/analyze under the multiple psuedo-random patterns to make a flat physical RAM space).

So, for certain very-specific threat models you will want to institute very strict set behavioral controls, those being: a) never leave your device unsupervised and if you do, consider it compromised and b) never leave your device powered on (disk unlocked) where it may be seized by your adversary, even if the screen is locked.

As always data found must be exfiltrated. So, are there circumstances this technique might possible be used in a chained attack in some way? Maybe...but I strongly doubt that it's an instant win on Qubes.

Brendan

[Steve Coleman]

The best defense in my opinion is the low-tech solution. Since the exploit requires physical access to that port, you simply deny them that required access. 

If your machine has a physical thunderbolt port then buy yourself a locking plug and then use some glue to be sure that it never comes back out. Risk averted. 

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ad56d164-24fb-4d22-b5cf-c67d303c30d6%40googlegroups.com.

[Marek Marczykowski-Górecki]

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

In theory, my answer would be "IOMMU isolates Thunderbolt devices, so it
isn't a concern". But unfortunately practice can far from it:

1. As mentioned in the advisory, effective IOMMU isolation for
Thunderbolt is available in hardware produced in 2019+ only.

2. Configuring IOMMU for hot-pluggable devices is generally racy.

In Qubes we do disable PCI hotplug handling in kernel, but that's only a
small obstacle for the attacker, in many cases bypassable
- - unless proper IOMMU configuration is applied at the right time, in
many cases device can access host memory even if no driver is loaded
for it.

So, my advice would be to disable Thunderbolt until further notice.

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl67OOYACgkQ24/THMrX
1yy7ggf9GIWc6+/lXO0P3TozLj7iIaBIUkZtT/OerXywiNivnPrRQ4Ybmmia/UQ+
mF07GsDBzxv6ZxSVEdw3YjGqJpwvVbb1fCXeeb7Nd98GpwKmzfbL07JKZ8Bkp1Mf
pYeEXfZk4MwVsGwwxJB7mjtWoaYMSFE391Ql/njquLFFCo70FPt+NN5yY+wuv5SA
KardT7UG0a5tn7IabyaAU7Bx7Q1rU9gZVvm6EHy//tSqxMw4VXhAmXo7uoeaUiUL
Bvq2ls/2B/eIbhm0HDv3cmDaeOUOYMaejdGkIvlhRxBzN5E4tOqrsrGxnpzpMFiI
3yTgFIL2gU1yCsniei7/9Gxbp8Te0A==
=iVxs
-----END PGP SIGNATURE-----

[Brendan Hoar]

On Tuesday, May 12, 2020 at 8:01:50 PM UTC-4, Marek Marczykowski-Górecki wrote:

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

On Tue, May 12, 2020 at 06:22:50AM -0700, bradbury9 wrote:
> Looks like a new evil maid attack [1][2] that takes advantage of the
> thunderbolt port is on the wild.
>
> I do recall Qubes OS had anti evil maid features. I wonder, are Qubes OS
> protected against this new attack?
>
> [1]: https://www.schneier.com/blog/archives/2020/05/attack_against_2.html
> [2]: https://www.wired.com/story/thunderspy-thunderbolt-evil-maid-hacking/

In theory, my answer would be "IOMMU isolates Thunderbolt devices, so it
isn't a concern". But unfortunately practice can far from it:

1. As mentioned in the advisory, effective IOMMU isolation for
Thunderbolt is available in hardware produced in 2019+ only.

2. Configuring IOMMU for hot-pluggable devices is generally racy.

In Qubes we do disable PCI hotplug handling in kernel, but that's only a
small obstacle for the attacker, in many cases bypassable
- - unless proper IOMMU configuration is applied at the right time, in
many cases device can access host memory even if no driver is loaded
for it.

So, my advice would be to disable Thunderbolt until further notice.

Hmm...

Well, if the attack requires that the thunderbolt chipset firmware be compromised via *physical attack*, I suppose the attacker would also compromise the UEFI/BIOS firmware during the physical attack, leaving the UEFI/BIOS showing the device disabled, but...really, leaving it active enough for attack.

B

[Marek Marczykowski-Górecki]

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

In case of many laptops, OEMs enable BootGuard, which detects UEFI/BIOS
modifications (and also prevents installing coreboot at the same time).
So, this isn't that easy. UEFI/BIOS is quite complex piece of code, so
it's quite possible to find some bug that allows attack it a different
way. But it isn't as easy as directly modify it on the flash.

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl67UpEACgkQ24/THMrX
1ywvfQf+MZCX6iuBGvdVAmHLr2leAy2Dp5WrcxH5jJByq7QjPE/PjvXpw8K1QjZd
2Wq7xr6YS162SDVbBCnJXjZEPoIfE276n/EHu3NVtbOlCmqvZ5lHN36AGSikxSPY
jOZ0MImgy9sTbulE1cbc36Mp1WambMqobsNaQMnicorNakpXelEtDOXulRngMNT8
e23Z05+zvSb6jDib3IrmK8L+gkvA0Ymwzn8DtptEUe/22Hptdb7DJFQ3sMwBi8eC
8NYWmo3tCuS9KNFuzq/UriGpzJKdTj3qHBIb0t0UPoJKFYC6bAVlbMy90Jy3Dmvx
lTrNAHPGIARY4P8EULFPTEJ+Y5VAqQ==
=hWb3
-----END PGP SIGNATURE-----