Geekly Articles each Day
📜 ⬆️ ⬇️

About UEFI security, part two

We continue the conversation begun in the past about UEFI security, about threats and the existing defenses against them.
This time it will be about SMM, how it works and works, and why it is the desired target for an attack.
I missed zero and the first part of this opus - I recommend reading them first, I humbly ask the rest for kat.

Part two. SMM


A little bit of educational program
Thanks to search engine optimization and network marketing specialists (if they are healthy!), It’s absolutely impossible to find information on SMM on the SMM web site, you constantly come across offers to increase, speed up and improve, so we will conduct educational campaign without departing from projectile.
System Management Mode is one of the most privileged code execution modes for x86 / amd64-compatible processors, which first appeared in the special SL version of the Intel 80386. Starting from 80486, it is supported by all x86 CPUs, including those made by AMD and VIA.
Initially, SMM was used for OS-independent implementation of automatic power management and system devices, since to teach this OS of the time was more difficult than adding another execution mode to the processor.
The transition to the SMM mode is performed only with the help of a special interrupt - SMI , which is generated in various ways:
- hardware, high level output to SMI output #
- by the system itself, as a result of some events
- programmatically, sending a byte to the CPU IO-register with a given number (most often it is register 0xB2)

Hardware SMI
There is nothing special to write about him: we put pressure on the leg - we have an interruption. Now rarely used, because almost all systems now have multifunctional GPIOs that can generate events without interrupting the OS, plus no additional logic is needed to determine who specifically generated hardware SMI, because there are many devices and one leg.

System SMI
There are quite a few sources of system SMIs, I will list only those that can be controlled, including disabling them at the request of the firmware developer, taking the system with the eighth series chipset, i.e. Haswell / Broadwell processor:

SMI software
Software SMIs are most often generated either by firmware or drivers, but nothing prevents an attacker with administrator rights in the OS (more precisely, the rights to execute the out instruction are required) to also generate them.
Software SMI is generated when writing to the CPU IO-port APM_CNT (most often it is port 0xB2), its number is transmitted as a parameter in the AL register. Thus, the maximum number of different software SMI handlers in the system is 256, but in reality they range from 0-5 on specialized systems prepared for working with RTOS, up to 15-20 on systems with lots of different hardware that need to be managed without OS intervention.
')
How is SMM implemented
For the SMM dispatcher code and SMI handlers, 1-3 real memory areas are allocated, which in all “normal” execution modes the chipset marks as an MMIO area with a non-existent device, i.e. for the rest of the world, these areas are a continuous series of 0xFF that cannot be rewritten. The first area, commonly called ASEG (i.e., “Segment A”), is intended for so-called. legacy SMM code , i.e. old 16-bit SMI handlers, which no longer exist on modern systems. The segment got its name because it is located at fixed physical addresses 0xA0000 - 0xBFFFF. The second area with fixed addresses is HSEG (i.e., “high segment”), previously it was at 0xFEDA0000 - 0xFEDBFFFF, but on modern systems it is not used, because there is a much more convenient segment with customizable addresses and sizes — TSEG (i.e., “top segment”), in which 99% of the code executed in SMM are now located, and in ASEG there is only a small stub for compatibility.
When switching to SMM, the processor retains almost the entire context (i.e. the contents of almost all registers, which ones are not saved — depends on the specific micro-architecture), and the SMI handlers have full access to the saved context, and therefore it can communicate with the system through changing saved values.
For an OS, a call to SMM code looks like a magical change in the contents of registers and memory, and although it is still possible to track the length of stay in SMM by indirect signs, and the fact of transition into it is direct, by reading the MSR_SMI_COUNT register before and after calling the program interrupt but it cannot affect the length of the SMI OS handler, so SMM is not very compatible with hard-RTOS (it is worth noting that the entire x86 architecture is compatible with them quite a time, but this is another story).
With the default settings, the code working in SMM has full access to all physical memory for reading and writing, full access to all connected devices, in general, it can do almost everything, and is independent of the OS and is not accessible from it even for reading, which is very makes it difficult to analyze and makes the code of SMI handlers a very attractive target for an attack. Moreover, if the attacked system is accessible from the SMM record on the SPI chip (and it is available in all cases, except for systems with PFAT enabled, which cannot be found with fire, Read-only BIOS systems, which are even less common, and systems protected by PR registers), then a successful attack can end up writing its code in the BIOS, followed by theft, murder, and lewdness with geese. That is why protecting the SMM from inserting malicious code there is vital.

SMM attacks and protection against them
Forgotten D_LOCK
The code in SMRAM does not appear on its own, first you need to configure SMRAM itself, initialize the physical memory, configure TSEG so that all handlers fit in there, copy the code of the SMM dispatcher and handlers there, set up descriptor tables there - in general, establish strict statutory order, after which it is necessary to remove the D_OPEN bit so that no one else spoils anything there, and set the D_LOCK bit so that D_OPEN cannot be put back. On some older systems, it was forgotten to install D_LOCK, and there the SMM was exposed to all winds, but this is no longer the case in the UEFI era, so this attack vector has gone down in history.

SMM cache poisoning
Another historical attack is SMRAM cache poisoning , which was published in 2009 by Rafal Wojtczuk and Joanna Rutkowska. The essence of the attack is short - we change the memory type for the SMRAM region to Write-Back, organize our SMRAM code to write to the SMRAM region, do not write to the memory, but our code remains in the second-level cache, after which we generate software SMI and the processor does not read the data from SMRAM, and from the cache, and executes our malicious code. The problem was solved radically - CPU manufacturers banned the installation of WB mode on SMRAM, and therefore the system with UEFI is not affected by this vulnerability.

SMM call-out, she is SMM incursion attack
But enough history, let's move on to the "modern" attacks. Let's begin, perhaps, with the very SMM Incursion Attack, about which Comrade. maseal mentioned in the comments to the first part. I specifically put the word “modern” in quotation marks, because this attack was a hundred years old at lunch, it was first reported about it in 2008 as a problem for the then BIOSs, but in 2015 it was rediscovered by Corey Kallenberg and Xeno Kovah again. The attack is as simple as mooing - if an SMI handler calls any code outside of SMRAM, then an attacker with write access to physical memory can replace the called code with his own and execute it in SMM mode this way. And since Since UEFI developers are accustomed to the availability of EFI Runtime services, these same services were consistently called from SMI handlers for every other (most often these were calls to GetVariable, SetVariable, and ResetSystem). Vulnerability has been exposed to so many systems that it is easier to say where they were not. In my rough estimate, if your UEFI is older than May-June 2015 for build date, it is guaranteed to have a couple of SMI handlers vulnerable to this attack. Cleaning the system from such buggy handlers is quite difficult, and since Previously, this behavior was not considered a vulnerability at all (“What kind of fool would get services to hook that ?!”) and that it was impossible to do this was not known to simple IBV coders — even now, updates for runtime drivers are prone to this problem . All very sad in general.
To protect against calling an external SMRAM code, Intel engineers added a special MSR_SMM_FEATURE_CONTROL, after setting a certain bit in which calling this code generates a non-maskable and unrecoverable MCE , but there is such a MSR only in Haswell and newer CPUs, and this feature is enabled only on firmware debugging time, otherwise users may come to the door of the R & D department with forks and dubjees for incomprehensible hangs on level ground - most people need to work now, and this is all your security is overhyped. For owners of older systems and systems based on AMD processors, Phoenix engineers found an ingenious solution of their own - to use NX bits, adjusting the memory for the SMM code so that the code call outside SMRAM ends with Page Fault, which can then be processed, and Do not hang tightly on the MCE. I repent, I haven’t implemented this decision yet, but when the hands reach, I will definitely do it.
A simple user can be protected from this attack only by not allowing the execution of an incomprehensible code from the root, but this, unfortunately, is almost impossible on modern operating systems - there are options for local elevation of rights, and the sea remains how many such 0day exploits are on hand and turnover is impossible to say. It remains only to quote the aforementioned Xeno Kovah:
Please, please, go apply patches!

DMA attack
Another interesting attack, this time - with the help of its own chipset. The fact is that modern chipsets have a DMA controller, which is used to unload the CPU from transferring data from memory to memory, both between DRAM and between DRAM and memory of PCIe devices. Moreover, to initiate such a transfer can both the OS and the PCIe device, which can also have its own DMA controller. Moreover, in the case of initiation from the OS, the chipset performs the data access operation, i.e. if any processor settings affect it, it is rather weak. Those. An attacker with administrative rights initiates a DMA with a memory area controlled by it on the one hand and SMRAM on the other, and gets full access to it. The same can be done by the firmware controlled by the attacking PCIe device. To protect against DMA attacks, Intel's DMA controllers have a TSEGMB register in which the TSEG location information is duplicated, and the Lock bit, which prohibits this content to be changed. If the authors of the firmware forgot to install (or restore at the start after S3, but this is in the next part) - you can attack. I do not know if AMD chipsets have protection against DMA attacks, but I will try to find out in the near future.

SMM cross-buffer attack
Introduced by specialists from Intel ATR attack on SMI handlers, which take as a parameter a pointer and buffer size, and write to it. The attacker can pass the pointer and size so that the buffer crosses the RAM-SMRAM boundary, but since If the SMI handler has access to SMRAM, then it will overwrite some of the data at the beginning of SMRAM. With the best of luck (i.e., after about 500 hours of debugging at least), the handler can rewrite the service structures of the SMM dispatcher or other handlers in the desired attacking manner, and he will be able to execute arbitrary SMM code. The attack is hellishly complex and targeted, but quite possible, so from the beginning of 2015, all SMI handlers that take pointers to the buffer must validate it before use. On older systems, the attack will work, but the likelihood that you will be hacked through it is low.

Conclusion


Well, now we have understood more or less with SMM, in the next part we will talk about attacks on S3 BootScript .
Thank you for your attention, safe for you firmware.

PS
I can not thank Comrade. d_olex for his articles on SMM and attacks on him - one and two times . For those interested in the topic and who can read in English - both are required to read.

Source: https://habr.com/ru/post/267197/

More articles:


All Articles