Introduction
During our recent talk at HardwearIO (see here, slides here) we described a variety of AMD platform misconfigurations that could lead to critical vulnerabilities, such as:
- TSEG misconfigurations breaking SMRAM protections
- SPI controller misconfigurations allowing SPI access from the OS
- Platform Secure Boot misconfigurations breaking the hardware root-of-trust
Here we are providing a brief overview of essential registers settings and explain how our internally developed tool Platbox (see here) can be used to verify them and ultimately exploit them.
SMM Protections
In a previous blog post about AMD platform security (see here) we explained how forgetting to set a single lock can lead to a complete compromise of System Management Mode (SMM).
To recap, on modern systems SMM lives in a protected memory region called TSEG and four Model Specific Registers (MSRs) need to be configured to guarantee these protections:
- 0xC0010111 (SMM_BASE; base of SMM code)
- 0xC0010112 (SMMAddr; defines TSEG base address)
- 0xC0010113 (SMMMask; defines TSEG limit and TSEG enable bit)
- 0xC0010015[SmmLock] (HWCR; defines lock of the aforementioned MSRs)
In the following we can see a breakdown of the aforementioned registers using Platbox on the Acer Swift 3 (model no. SF314-42; BIOS v1.10):
As marked in the output, the SMMLock bit in the Hardware Configuration Register (HWCR) hasn’t been set and therefore the TSEG region protections can simply be disabled by a privileged OS attacker by disabling the TValid bit in the SMMMask MSR.
Additionally, to ensure that the SMM code lies within the protected TSEG region, one should also confirm that the SMM base address (stored in the SMM_BASE MSR) lies inside of TSEG. In most cases the EDK2 framework will ensure that this is the case. It is also interesting to notice that SMM_BASE is also locked when SMMLock is set, thus preventing relocation attacks.
One additional register that is relevant to the security of SMM is the SMM key register (stored in the SMM_KEY MSR at 0xC0010119; see p630 in [1]). This is a write-only MSR that can be set before SMMLock to create a password-protected mechanism to clear SMMLock later on.
As mentioned in our presentation, while we haven’t found an OEM using this register, we used it as part of an exploit to demonstrate persistence in vulnerable platforms.
SPI Flash Protections
The SPI flash plays an important role in the context of platform security as it is used to store both the UEFI BIOS firmware code and configuration data (e.g. the Secure Boot state).
Architecturally, firmware code should only be modified at boot-time during firmware updates (via signed capsule updates) whereas portions of configuration data can be modified at run-time (in a controlled way via SMM).