| Summary |
UEFI のリファレンス実装である EDK1 にはバッファオーバーフローの脆弱性が存在します。 オープンソースのプロジェクト EDK1 は Unified Extensible Firmware Interface (UEFI) のリファレンス実装を提供しています。商用の UEFI 実装は EDK1 のソースコードを取り込んでいる可能性があります。Rafal Wojtczuk 氏と Corey Kallenberg 氏の調査によると、Edk1/source/Sample/Universal/Variable/RuntimeDxe/FS/FSVariable.c にはバッファオーバーフローの脆弱性が存在します。 Corey Kallenberg 氏は本脆弱性を次の通り説明しています。 "UEFI utilizes various non-volatile variables to communicate information back and forth between the operating system and the firmware; for instance, boot order, platform language, etc. These non-volatile variables are stored in a file-system like region on the SPI flash chip. This file-system supports many operations such as deleting existing variables, creating new variables, and defragmenting the variable region in order to reclaim unused space. This latter operation is important to ensure that large variables can be created in the event the variable region is resource constrained and fragmented with many unused "free slots." We have discovered a buffer overflow associated with this "reclaim" operation [in FSVariable.c]. FSVariable.c https://github.com/tianocore/edk/blob/master/Sample/Universal/Variable/RuntimeDxe/FS/FSVariable.c#L348-L352 In the reclaim operation, there is assumption that by following the chain of variables (by NextVariable = GetNextVariablePtr (Variable), that essentially adds Variable's size to it), we do not jump out of the variable store bounds. In particular, in line 352, the CurrPtr can extend beyond the legitimate boundaries of the variable region. Ultimately in line 350, we can end up with a memory corruption via buffer overflow."
|
| Possible impacts |
Rafal Wojtczuk 氏と Corey Kallenberg 氏は脆弱性の影響について次のように述べています。 "The impact of the vulnerability depends on the earliness at which the vulnerable code can be instantiated. Generally, as the boot up of the platform progresses, the platform becomes more and more locked down. Specifically, things like the SPI Flash containing the platform firmware, SMM, and other chipset configurations become locked. In an ideal (for attacker) scenario, the vulnerable code can be instantiated before the SPI flash is locked down, thus resulting in an arbitrary reflash of the platform firmware. Another possibility is for the attacker to leverage this vulnerability to get into SMM (if SMM is not sufficiently locked down yet), or to defeat Secure Boot and launch an authorized boot loader. It is also possible that this code is copied into SMM to support the ability to create/modify authenticated variables at runtime, in which case, the vulnerability could be exploited to achieve a runtime SMM break-in. The consequences and exploitablity of this bug will vary based on the OEM's firmware implementation." |