[coreboot] [Resend] Tapping into the core (33C3)

[Taiidan at gmx.com]

On 01/18/2017 08:08 AM, Denis 'GNUtoo' Carikli wrote:

> On Tue, 17 Jan 2017 11:11:38 +0000
> Maxim Goryachy <mgoryachy at 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.
>
Does IOMMU protect someone from this assuming all the USB controllers 
are assigned to a VM?