On Tuesday, May 12, 2020 at 9:22:50 AM UTC-4, 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 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 -- 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+unsubscr...@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.
