137 lines
5.9 KiB
Markdown
137 lines
5.9 KiB
Markdown
Dealing with Untrusted Input in SMM
|
||
===================================
|
||
|
||
Objective
|
||
---------
|
||
Intel Security recently held a talk and published
|
||
[slides](http://www.intelsecurity.com/advanced-threat-research/content/data/REConBrussels2017_BARing_the_system.pdf)
|
||
on a vulnerability in SMM handlers on x86 systems. They provide examples
|
||
on how both UEFI and coreboot are affected.
|
||
|
||
Background
|
||
----------
|
||
SMM, the System Management Mode, is a CPU mode that is configured by
|
||
firmware and survives the system’s initialization phase. On certain
|
||
events that mode can be triggered and executes code, suspending the
|
||
current processing that is going on the CPU, no matter whether it’s
|
||
in kernel or user space.
|
||
|
||
In SMM, the CPU has access to memory dedicated to that mode (SMRAM) that
|
||
is normally inaccessible, and typically some restrictions are lifted as
|
||
well (eg. in some configurations, certain flash write protection registers
|
||
are writable in SMM only). This makes SMM a target for attacks which
|
||
seek to elevate a ring0 (kernel) exploit to something permanent.
|
||
|
||
Overview
|
||
--------
|
||
Intel Security showed several places in coreboot’s SMM handler (Slides
|
||
32+) that could be manipulated into writing data at user-chosen addresses
|
||
(SMRAM or otherwise), by modifying the BAR (Base Address Register) on
|
||
certain devices. By picking the right addresses and the right events
|
||
(and with them, mutators on the data at these addresses), it might
|
||
be possible to change the SMM handler itself to call into regular RAM
|
||
(where other code resides that then can work with elevated privileges).
|
||
|
||
Their proposed mitigations (Slide 37) revolve around making sure
|
||
that the BAR entries are reasonable, and point to a device instead of
|
||
regular memory or SMRAM. They’re not very detailed on how this could
|
||
be implemented, which is what this document discusses.
|
||
|
||
Detailed Design
|
||
---------------
|
||
The attack works because the SMM handler trusts the results of the
|
||
`pci_read_config32(dev, reg)` function, even though the value read by that
|
||
function can be modified in kernel mode.
|
||
|
||
In the general case it’s not possible to keep the cached value from
|
||
system initialization because there are legitimate modifications the
|
||
kernel can do to these values, so the only remedy is to make sure that
|
||
the value isn’t totally off.
|
||
|
||
For applications where hardware changes are limited by design (eg. no
|
||
user-modifiable PCIe slots) and where the running kernel is known,
|
||
such as Chromebooks, further efforts include caching the BAR settings
|
||
at initialization time and comparing later accesses to that.
|
||
|
||
What "totally off" means is chipset specific because it requires
|
||
knowledge of the memory map as seen by the memory controller: which
|
||
addresses are routed to devices, which are handled by the memory
|
||
controller itself?
|
||
The proposal is that in SMM, the `pci_read_config` functions (which
|
||
aren’t timing critical) _always_ validate the value read from a given
|
||
set of registers (the BARs) and fail hard (ie. cold reset, potentially
|
||
after logging the event) if they’re invalid (because that points to
|
||
a severe kernel bug or an attack).
|
||
The actual validation is done by a function implemented by the chipset code.
|
||
|
||
Another validation that can be done is to make sure that the BAR has the
|
||
appropriate bits set so it is enabled and points to memory (instead of
|
||
IO space).
|
||
|
||
In terms of implementation, this might look somewhat as follows. There
|
||
are a bunch of blanks to fill in, in particular how to handle the actual
|
||
config space access and there will be more registers that need to be
|
||
checked for correctness, both official BARs (0-4) and per-chipset
|
||
registers that need to be blacklisted in another chipset specific
|
||
function:
|
||
|
||
```c
|
||
static inline __attribute__((always_inline))
|
||
uint32_t pci_read_config32[d](pci_devfn_t dev, unsigned int where)
|
||
{
|
||
uint32_t val = real_pci_read_config32(dev, where);
|
||
if (IS_ENABLED(__SMM__) && (where == PCI_BASE_ADDRESS_0) &&
|
||
is_mmio_ptr(dev, where) && !is_address_in_mmio(val)) {
|
||
cold_reset();
|
||
}
|
||
return val;
|
||
}
|
||
```
|
||
|
||
`is_address_in_mmio(addr)` would be a newly introduced function to be
|
||
implemented by chipset drivers that returns true if the passed address
|
||
points into whatever is considered valid MMIO space.
|
||
`is_mmio_ptr(dev, where)` returns true for PCI config space registers that
|
||
point to BARs (allowing custom overrides because sometimes additional
|
||
registers are used to point to addresses).
|
||
|
||
For this function what is considered a legal address needs to be
|
||
documented, in accordance with the chipset design. (For example: AMD
|
||
K8 has a bunch of registers that define strictly which addresses are
|
||
"MMIO")
|
||
|
||
### Fully insured (aka “paranoid”) mode
|
||
For systems with more control over the hardware and kernel (such as
|
||
Chromebooks), it may be possible to set up the BARs in a way that the
|
||
kernel isn’t compelled to rewrite them, and store these values for
|
||
later comparison.
|
||
|
||
This avoids attacks such as setting the BAR to point to another device’s
|
||
MMIO region which the above method can’t catch. Such a configuration
|
||
would be “illegal”, but depending on the evaluation order of BARs
|
||
in the chipset, this might effectively only disable the device used for
|
||
the attack, while still fooling the SMM handler.
|
||
|
||
Since this method isn’t generalizable, it has to be an optional
|
||
compile-time feature.
|
||
|
||
Caveats
|
||
-------
|
||
This capability might need to be hidden behind a Kconfig flag
|
||
because we won’t be able to provide functional implementations of
|
||
`is_address_in_mmio()` for every chipset supported by coreboot from the
|
||
start.
|
||
|
||
Security Considerations
|
||
-----------------------
|
||
The actual exploitability of the issue is unknown, but fixing it serves
|
||
as defense in depth, similar to the
|
||
[Memory Sinkhole mitigation](https://review.coreboot.org/#/c/11519/) for
|
||
older Intel chipsets.
|
||
|
||
Testing Plan
|
||
------------
|
||
Manual testing can be conducted easily by creating a small payload that
|
||
provokes the reaction. It should test all conditions that enable the
|
||
address test (ie. the different BAR offsets if used by SMM handlers).
|