Adding notes: If ioperm/iopl are necessary to enable DCI on GNU/Linux, two tiny features from PaX/Grsecurity can mitigate such attack: CONFIG_GRKERNSEC_KMEM, CONFIG_GRKERNSEC_IO
On Wed, Jan 18, 2017 at 9:08 PM, Denis 'GNUtoo' Carikli GNUtoo@no-log.org wrote:
On Tue, 17 Jan 2017 11:11:38 +0000 Maxim Goryachy mgoryachy@ptsecurity.com wrote:
[...]
If I understand correctly, when DCI is disabled in the flash descriptor, such attacks are not possible and the computer is safe.
Unfortunately no, DCI can be activated through P2SB device at any time. We checked it on Skylake and Kabylake.
As I understand from the datasheet screenshot on the slides, the P2SB device is a PCIe device, and to enable DCI you have to:
Write to the DCI IO port. Under GNU/Linux you typically need to be root to write to IO ports (man 2 iopl).
Write to to the P2SB SBREG BAR. Under GNU/Linux probably needs root too.
I don't know well enough the datasheet of x86 chipsets to be able to tell if there are more ways to restrict that access than using the CPU's privileges rings. If there are such ways, it might be possible to make use of them with Coreboot.
Since I didn't understand what "PCH sideband interface" is, so I cannot tell if the ways mentioned above (IO port and BAR) would be accessible form other devices than the CPU, if it does, to have a secure laptop you would need:
- Not to have the PCIe bus exposed on any external connector (no thunderbolt).
- Not to have any malicious PCIe device, or PCIe device that can be abused to write to the register of the P2SB device by either malicious hardware or non-privileged code. I wonder if protecting against such attacks is even possible if we use modern GPUs.
So to summarize:
If DCI is disabled on the flash descriptor:
- On skylake hardware, if you have root, you can, with a simple USB3 cable you can:
- (1) Execute code in kernel mode.
- (2) Execute code in hypervisor mode.
- (3) Execute code in SMM.
- An attacker that is sitting in front of your laptop[1][2] can't magically take control of your computer by plugging an USB device in it. The attacker first needs to enable DCI, and that requires root privileges under GNU/Linux (for access to the IO space or to the PCI BARs address space).
So if an attacker need both root and physical access to be able to do some privilege escalation, it shouldn't be a big issue.
An attacker then might try to do remote privilege escalation, for instance by:
- Programming that USB device with kernel privileges to send DCI commands.
- Programming any USB device on the same bus to send DCI commands
- Programming any nearby devices to do spoofing and send DCI commands.
However, as far as I understand:
- There are other ways than SMM to protect the boot flash and prevent the OS from reflashing it. I'd guess that if the boot firmware is written correctly, and that there are no huge hardware flaws, such ways are reliable, but I don't know everything. One way would be, to ask the flash chip to do it, that is to prevent writing until the next reboot. There are patches for flashrom to support such features. It is also possible to add support for theses in Coreboot.
- Practical virtual machine escape is not possible that way either, because you need either access to the PCIe bus or the P2SB PCIe device, and users, distribution maintainers and virtual machine providers typically won't export the P2SB PCIe device in a virtual machine, right?
Some questions:
- Can the debug port be used as an usb device controller?
Sorry? I don't understand the question.
"USB devices controller" are called by many different names, so it doesn't help clarity, so I'll rephrase. Can the USB debug port be used as an USB OTG port, like on Android smartphones, where you can make the smartphone appear as a mass storage device, serial port, Ethernet card and so on.
References:
[1] Here I assume that the attacker has no way to disassemble the laptop without being noticed. [2] The laptop could be on, off, or in suspend-to-ram. If the laptop is on or suspended, the attacker might have better chances trying to bypass the screensaver for instance.
Denis.
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot