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

[Denis 'GNUtoo' Carikli]

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.