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 <[email protected]> wrote: > On Tue, 17 Jan 2017 11:11:38 +0000 > Maxim Goryachy <[email protected]> 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: [email protected] > https://www.coreboot.org/mailman/listinfo/coreboot -- GNU powered it... GPL protect it... God blessing it... regards Shawn -- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
