Hi,
I saw your presentation "Tapping into the core"[1] that you gave at the last CCC.
As I understand from the slides DCI can be activated trough: - The flash descriptor - UEFI - The P2SB register
Are skylake platform safe if: - DCI is disabled in the flash descriptor. - DCI is not activated by the boot firmware(UEFI or coreboot). - DCI is not activated troug the P2SB register.
All the above require either code execution on the machine or to open the machine with a screwdriver and reprogram the flash with an external flash programmer.
If DCI is enabled in the flash descriptor, then the following attacks can benefit from an enabled-by-default DCI: - Malicious USB devices trying to take over the computer. - Evil maid attacks when trying to bypass the TPM. This might or might not work depending on how the TPM application inside the Management engine works.
If I understand correctly, when DCI is disabled in the flash descriptor, such attacks are not possible and the computer is safe.
Since skylake computer can be secured, the feature would become an enormous advantage: Coreboot developers might be able to use that feature to make debugging and replacing intel blobs faster and easier. Having more information on the protocol or free software and open source tools would help. This might also be useful for debugging the Linux kernel or other hardware related projects.
It might also be possible to run coreboot on laptops with bootguard: Some programable[1] USB3 device controller exist, if a tiny enough USB key can be made, it might be possible to bypass bootguard this way. Users doing that would then be able to use coreboot on more recent computers.
Some questions: - Can the debug port be used as an usb device controller? - What is the relationship between DCI and the Management Engine? Can the Management Engine be controlled trough DCI? - Do you have more documentation on the protocol? Is it possible to have the slides?
By the way, coreboot and libreboot have several utilities related to the flash descriptor: - ifdtool[3] - ich9gen[4]
PS: Sorry for the inconvenience, due to bad exim configuration which will hopefully be fixed now, I've to resend the mail.
References: ----------- [1]https://media.ccc.de/v/33c3-8069-tapping_into_the_core [2]http://www.cypress.com/products/ez-usb-fx3-superspeed-usb-30-peripheral-cont... [3]utils/ifdtool in coreboot sources. [4]resources/utilities/ich9deblob in libreboot sources.
Denis.
On Mon, Jan 16, 2017 at 04:40:33PM +0100, Denis 'GNUtoo' Carikli wrote:
[...] As I understand from the slides DCI can be activated trough:
- The flash descriptor
- UEFI
- The P2SB register
Aren't there two different things being discussed here? There is DCI, which requires BIOS or firmware support, and SVT, which works even if if DCI is disabled and the system is powered down. According to Intel's site:
https://designintools.intel.com/product_p/itpxdpsvt.htm
The [SVT] tool enables closed-chassis use-cases where USB3-hosted DCI is limited, intermittent, or unavailable and includes initial cold boot, suspend-state operation and survival, Reset-flows, and USB3 or IOSF path failures.
During the 33c3 talk, the presenters mentioned that SVT provides its own power to the chipset and the protocol is undocumented (but perhaps could be reverse engineered).
[...] It might also be possible to run coreboot on laptops with bootguard: Some programable[1] USB3 device controller exist, if a tiny enough USB key can be made, it might be possible to bypass bootguard this way. Users doing that would then be able to use coreboot on more recent computers.
This is an interesting idea. If you can enable debugging during the BIOS or Startup ACM execution, an external device should be able to change the code execution path. I'm doubtful DCI will make it possible, however, since it seems that enabling DCI is something the firmware sets up after the ACM has run. SVT on the other hand...
Bootguard can be bypassed by simply swapping compatible CPU's from two computers/laptops, correct?
The bigger issue is, do we really want to support a company that will one day succeed in shutting us down? while x86 is the only real option for a mobile workstation I feel as though all desktop/server development should be focused on POWER as IBM isn't yet entirely hostile to the idea of free firmware (in 2012 a new kgpe-d16, compatible RAM, cpu's etc would be as much as a power habanero is now, it isn't really that expensive the only issue is that they don't depreciate in value as much as an x86 device so it isn't as easy to pick up older models for cheap)
What do you guys think?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/16/2017 03:34 PM, Taiidan@gmx.com wrote:
Bootguard can be bypassed by simply swapping compatible CPU's from two computers/laptops, correct?
The bigger issue is, do we really want to support a company that will one day succeed in shutting us down? while x86 is the only real option for a mobile workstation I feel as though all desktop/server development should be focused on POWER as IBM isn't yet entirely hostile to the idea of free firmware (in 2012 a new kgpe-d16, compatible RAM, cpu's etc would be as much as a power habanero is now, it isn't really that expensive the only issue is that they don't depreciate in value as much as an x86 device so it isn't as easy to pick up older models for cheap)
What do you guys think?
Fully agree on servers and workstations. I'd personally love to see the community step up and fund the relatively small amount of remaining work required to completely free up the S822LC, for instance.
On mobile, I disagree some. Mobile would be best handled with ARM64 devices; for typical mobile tasks (mostly content consumption / remote terminal access to some other server(s)) the additional bit of computing power x86 provides is not worth the tradeoff in loss of owner control.
- -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com
On Mon, 16 Jan 2017 16:34:06 -0500 "Taiidan@gmx.com" Taiidan@gmx.com wrote:
Bootguard can be bypassed by simply swapping compatible CPU's from two computers/laptops, correct?
AFAIK, on many laptops the CPU is soldered now. Since such CPU are probably BGA, I don't see it as a viable option for most people. When people do not have enough skills to do something, commerce typically can bridge that gap, however I fear that: - The costs of such swap would be significant, I might be wrong though as the manufacturing technology evolves. - Users would have some psychological barrier about buying a laptop that is known to be worth a given price second hand or new, at a price that is way higher.
The bigger issue is, do we really want to support a company that will one day succeed in shutting us down?
The question for me is not between supporting or not supporting such company but rather when to stop supporting it entirely. More on that below.
while x86 is the only real option for a mobile workstation
It depend on the use case, people are different and use computing and technology differently. I currently use a Lenovo Thinkpad X60 as main computer. I currently do not need to compile huge quantity of source code like an entire GNU/Linux or Android distribution, so it works for me.
I did a compilation speed test between the Chromebook C201 and one of my X60, compiling u-boot on the C201 for the LG Optimus black took about 1/4 less time on the Chromebook. That said, even if the compiled code was exactly the same, the GNU/Linux distribution was not the same between both devices, and power management setup might have impacted the tests.
I feel as though all desktop/server development should be focused on POWER as IBM isn't yet entirely hostile to the idea of free firmware (in 2012 a new kgpe-d16, compatible RAM, cpu's etc would be as much as a power habanero is now, it isn't really that expensive the only issue is that they don't depreciate in value as much as an x86 device so it isn't as easy to pick up older models for cheap)
There is no doubt that, if we could, we should, as a community, focus on POWER8 and architectures friendly to free software.
However we might also want to think about how to handle the transition between both. A lot of people are still used to x86 hardware and some even still use legacy proprietary OS like Microsoft Windows.
More and more people are learning about privacy issues. A huge number of people also want to do something about it. According to Eben Moglen, that's about 1/5 of the Internet, that is about 400000 people.
More and more people will also realize its importance[7] as it would ruin people's lives (sic[9]). The damage caused by privacy leaks would probably probably increase a lot in the future (sic[9]), due to the kind of data that may be stored (think about your complete DNA) but also because the kind of information you will be able to deduce from the data will be way more sensitive than it is now[8], due to algorithmic progress on the relevant topics.
Free software and user control of the technology is required (but not sufficient by itself) to have some trustworthiness in our own computing and technology in general.
However many people (still) have a day job, a family, and no time for that. So how do you bring in so many people to free software? Especially if you need to change hardware, and that the new hardware won't run the legacy proprietary OS you were used to.
It might be possible if you split the issue in several parts: (1) A given person can start by migrating to GNU/Linux on hardware they have or are familiar with. We are still not there, since many people didn't switch yet, as the various jokes on "The year of the GNU/Linux desktop" reminds us. (2) Once the person migrated to GNU/Linux, on untrustworthy hardware, running it on trustworthy hardware might not be that different.
Having interacted with many (non-tech) people willing to switch to GNU/Linux or switching to it, I've an hypothesis on why very few people actually switched to GNU/Linux.
I think that it's mainly due to the lack of professional support for individuals: Most people still using legacy proprietary software can simply go to the computer shop nearby to get their software problem fixed. Such computer shop typically do not know how to fix common issues in GNU/Linux distributions. GNU/Linux user groups also don't scale enough to accommodate that much people, and are not available 7/7, and are often available the week-end, that is, when people want to spend time with their families instead of getting their computer fixed.
Increasing the availability of commercial support might be possible, for instance by identifying common issues and having a certification that would ensure that shops can fix such common issues with a good enough quality for most people. Few companies[1] seem to be involved in medium scale support of individuals (not businesses). Such companies probably have better information on what the common issues are than the GNU/Linux user groups, as they interact with more diverse people.
To help such user transitioning we also probably need computers that are made to ensure that GNU/Linux runs fine, even if they are x86 and run proprietary blobs in the boot firmware. This is made possible by Coreboot since the OS<->Boot firmware interface is free software. There is also at least one free software friendly company[2] that design laptops, and that are exercising some control over the choice of components that goes into such laptops.
Now helping people transition to use GNU/Linux isn't enough, we also need to make sure that hardware that respects people's free do exist at the end of the transition, and that such hardware also works well.
Since the Crowdsupply campaign of the POWER8 "Talos Secure Workstation"[3] didn't work out, probably due to the lack of people willing to pay a (way) higher price than other free software friendly computers like the novena, how do we go from there?
We also need to bother about security, and ensure that computers that can run fully free software are also secure, that the security is unobtrusive and still encourage the user to experiment with the software and hardware.
As I understand the "Talos Secure Workstation" would also have shipped with a free software root of trust[4][5] that would be user modifiable.
Such hardware would also have permitted to experiment with different approaches on how to ensure that the computer remains trustworthy and has not been tempered with, without the knowledge of the owner of the computer, that is, the user.
As I understand it, this feature might go into some minifree desktops and servers in the future[6], so we will hopefully be able to do such experimentation.
References: ----------- [1]https://hypra.fr [2]https://puri.sm [3]https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstatio... [4]https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstatio... [5]https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstatio... [6]https://minifree.org/product/libreboot-d16/ [7]http://craphound.com/news/2016/07/03/peak-indifference-privacy-as-a-public-h... [8]https://media.ccc.de/v/33c3-8238-retail_surveillance_retail_countersurveilla... [9]That said we shouldn't wait for privacy issues to be solved automatically: - The cost of that waiting would be that many lives would be ruined. - That doesn't take into account the relationship between privacy and power. People might really really strongly want and require privacy but could be prevented to get it.
Denis.
I'm putting my time into riscv nowadays. The breaking point for me with ARM was their move to UEFI a few years back for 64 bit.
And remember, as open as ARM is now, that can end any time. It's still a licensed architecture. There was a time when x86 implementations were everywhere, in the way that ARM is today. You can see how that went.
I like Power but they've always had the problem that they're hot and expensive and power hungry, and while that's fine in their target environment it's not where I want to be.
ron
On 16.01.2017 18:41, Denis 'GNUtoo' Carikli wrote:
Hello Denis.
Thank you for interest to our talk.
Hi,
I saw your presentation "Tapping into the core"[1] that you gave at the last CCC.
As I understand from the slides DCI can be activated trough: - The flash descriptor - UEFI - The P2SB register
Are skylake platform safe if: - DCI is disabled in the flash descriptor. - DCI is not activated by the boot firmware(UEFI or coreboot). - DCI is not activated troug the P2SB register.
All the above require either code execution on the machine or to open the machine with a screwdriver and reprogram the flash with an external flash programmer.
If DCI is enabled in the flash descriptor, then the following attacks can benefit from an enabled-by-default DCI: - Malicious USB devices trying to take over the computer. - Evil maid attacks when trying to bypass the TPM. This might or might not work depending on how the TPM application inside the Management engine works.
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.
Since skylake computer can be secured, the feature would become an enormous advantage: Coreboot developers might be able to use that feature to make debugging and replacing intel blobs faster and easier. Having more information on the protocol or free software and open source tools would help. This might also be useful for debugging the Linux kernel or other hardware related projects.
It might also be possible to run coreboot on laptops with bootguard: Some programable[1] USB3 device controller exist, if a tiny enough USB key can be made, it might be possible to bypass bootguard this way. Users doing that would then be able to use coreboot on more recent computers.
I think it is possible. I'm using DCI for BIOS research.
Some questions: - Can the debug port be used as an usb device controller?
Sorry? I don't understand the question.
- What is the relationship between DCI and the Management Engine? Can the Management Engine be controlled trough DCI?
I think it is two different device into PCH. They have some shared register, but We haven't research it yet entirely .
- Do you have more documentation on the protocol? Is it possible to have the slides?
We are planning to write a paper about protocol and driver for support DCI.
By the way, coreboot and libreboot have several utilities related to the flash descriptor: - ifdtool[3] - ich9gen[4]
PS: Sorry for the inconvenience, due to bad exim configuration which will hopefully be fixed now, I've to resend the mail.
References: ----------- [1]https://media.ccc.de/v/33c3-8069-tapping_into_the_core [2]http://www.cypress.com/products/ez-usb-fx3-superspeed-usb-30-peripheral-cont... [3]utils/ifdtool in coreboot sources. [4]resources/utilities/ich9deblob in libreboot sources.
Denis.
Sorry, I forgot to attach slides.
On 16.01.2017 18:41, Denis 'GNUtoo' Carikli wrote:
Hello Denis.
Thank you for interest to our talk.
Hi,
I saw your presentation "Tapping into the core"[1] that you gave at the last CCC.
As I understand from the slides DCI can be activated trough: - The flash descriptor - UEFI - The P2SB register
Are skylake platform safe if: - DCI is disabled in the flash descriptor. - DCI is not activated by the boot firmware(UEFI or coreboot). - DCI is not activated troug the P2SB register.
All the above require either code execution on the machine or to open the machine with a screwdriver and reprogram the flash with an external flash programmer.
If DCI is enabled in the flash descriptor, then the following attacks can benefit from an enabled-by-default DCI: - Malicious USB devices trying to take over the computer. - Evil maid attacks when trying to bypass the TPM. This might or might not work depending on how the TPM application inside the Management engine works.
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.
Since skylake computer can be secured, the feature would become an enormous advantage: Coreboot developers might be able to use that feature to make debugging and replacing intel blobs faster and easier. Having more information on the protocol or free software and open source tools would help. This might also be useful for debugging the Linux kernel or other hardware related projects.
It might also be possible to run coreboot on laptops with bootguard: Some programable[1] USB3 device controller exist, if a tiny enough USB key can be made, it might be possible to bypass bootguard this way. Users doing that would then be able to use coreboot on more recent computers.
I think it is possible. I'm using DCI for BIOS research.
Some questions: - Can the debug port be used as an usb device controller?
Sorry? I don't understand the question.
- What is the relationship between DCI and the Management Engine? Can the Management Engine be controlled trough DCI?
I think it is two different device into PCH. They have some shared register, but We haven't research it yet entirely .
- Do you have more documentation on the protocol? Is it possible to have the slides?
We are planning to write a paper about protocol and driver for support DCI.
By the way, coreboot and libreboot have several utilities related to the flash descriptor: - ifdtool[3] - ich9gen[4]
PS: Sorry for the inconvenience, due to bad exim configuration which will hopefully be fixed now, I've to resend the mail.
References: ----------- [1]https://media.ccc.de/v/33c3-8069-tapping_into_the_core [2]http://www.cypress.com/products/ez-usb-fx3-superspeed-usb-30-peripheral-cont... [3]utils/ifdtool in coreboot sources. [4]resources/utilities/ich9deblob in libreboot sources.
Denis.
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.
On 01/18/2017 08:08 AM, Denis 'GNUtoo' Carikli 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.
Does IOMMU protect someone from this assuming all the USB controllers are assigned to a VM?
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
Hello Denis.
On Tue, 17 Jan 2017 11:11:38 +0000 Maxim Goryachy mgoryachy@ptsecurity.commailto: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?
You are partially right. But on my target system DCI setting saves after shutdown or reboot (Documentation says that this setting is stored in th CMOS). And I see fellow: 1. Attacker switch on DCI through P2SB (boot disk or UEFi-shell for example); 2. Unlock IA32_DEBUG_INTERFACE (via resetbreak for example); 2. Attacker can take control of you computer by plugging an USB device in it.
But your right, you need have root permission for enable DCI. After that you can rewrite BIOS bypassing all security checks.
In my opinion, this technique more useful for research and debug.
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.
-
Denis 'GNUtoo' Carikli -
Maxim Goryachy -
ron minnich -
Shawn -
Taiidan＠gmx.com -
Timothy Pearson -
Trammell Hudson