.webp)
An attacker can exploit this vulnerability to elevate privileges from ring 0 to ring -2, execute arbitrary code in System Management Mode - an environment more privileged than operating system (OS) and completely isolated from it. Running arbitrary code in SMM additionally bypasses SMM-based SPI flash protections against modifications, which can help an attacker to install a firmware backdoor/implant into the BIOS. Such a malicious firmware code in the BIOS could persist across operating system re-installs. Additionally, this vulnerability potentially could be used by threat actors to bypass security mechanisms provided by the UEFI firmware (for example, Secure Boot and some types of memory isolation for hypervisors).
Binarly REsearch Team identified an SMM memory corruption vulnerability allowing a possible attacker to write fixed or predictable data to SMRAM. Exploiting this issue could lead to escalating privileges to SMM.
An attacker can exploit this vulnerability to elevate privileges from ring 0 to ring -2, execute arbitrary code in System Management Mode - an evironment more privileged than operating system (OS) and completely isolated from it. Running arbitrary code in SMM additionally bypasses SMM-based SPI flash protections against modifications, which can help an attacker to install a firmware backdoor/implant into the BIOS. Such a malicious firmware code in the BIOS could persist across operating system re-installs. Additionally, this vulnerability potentially could be used by threat actors to bypass security mechanisms provided by the UEFI firmware (for example, Secure Boot and some types of memory isolation for hypervisors).
The vulnerable module registers a child SW SMI handler with GUID 145f21ab-d92c-4eab-ab1e-5d24b90c3c6c:
gSmst->SmiHandlerRegister)(SmiHandler, &gUnknownProtocol145F21ABGuid, &Handle);
Also, it locates the protocol with GUID 2970687c-618c-4de5-b8f9-6c7576dca83d (implemented in SMM driver FwBlockServiceSmm GUID 74D936FA-D8BD-4633-B64D-6424BDD23D24):
gBuffer = AllocateBuffer(0x10);
if ( gSmst->SmmLocateProtocol)(&gUnknownProtocol2970687CGuid, 0, gBuffer + 8) >= 0 )
The handler is located at offset 0x2DC8:
EFI_STATUS __fastcall SmiHandler(EFI_HANDLE DispatchHandle, const void *Context, void *CommBuffer, UINTN *CommBufferSize)
{
if ( !CommBuffer )
return 0;
if ( !CommBufferSize )
return 0;
CommBufferSize_val = *CommBufferSize;
if ( *CommBufferSize != gCommBufferSize - 0x18 || CommBuffer != (char *)gCommBuffer + 0x18 )
return 0;
...
if ( *((_DWORD *)CommBuffer + 2) == 'AFMS' )
{
v8 = (char *)CommBuffer + 0x20;
v9 = (char *)CommBuffer + 0x28;
if ( *((_QWORD *)CommBuffer + 4) <= *CommBufferSize - 0x28 )
{
Status = EFI_UNSUPPORTED;
cmd = *((_DWORD *)CommBuffer + 6);
UnknownProtocol297067C = *(_QWORD *)(gBuffer + 8); // gSmst_2->SmmLocateProtocol)(&gUnknownProtocol297067CGuid, 0, gBuffer + 8)
if ( cmd )
{
cmd = cmd - 1;
// cmd = 2
if ( cmd )
{
if ( cmd != 1 )
{
LABEL_18:
*(_QWORD *)CommBuffer = Status;
return 0;
} // SmfbFunc3: SMM memory write
Status = (*(UnknownProtocol297067C + 0x18))(
*(_QWORD *)(gBuffer + 8),
*((_QWORD *)CommBuffer + 2),
v8,
v9);
}
// cmd = 1
else
{ // SmbFunc2: SMM memory write
Status = (*(UnknownProtocol297067C + 0x10))(
*(_QWORD *)(gBuffer + 8),
*((_QWORD *)CommBuffer + 2),
v8,
v9);
}
}
else
{
...
}
goto LABEL_18;
}
}
return 0;
}As we can see if a caller specifies *((_DWORD *)CommBuffer + 6) = 1 routine (*(UnknownProtocol297067C + 0x10))() will be called. It is implemented in SMM driver FwBlockServiceSmm GUID 74D936FA-D8BD-4633-B64D-6424BDD23D24, we call it as SmfbFunc2() (located at offset 0x1EBC) with controllable arguments passed into it:- addr (retrieved *((_QWORD *)CommBuffer + 2)) - main pointer for the operation- size (located at (_QWORD *)CommBuffer + 3) - size of data for the operation- dest (the rest of Communication Buffer located at (__int64)(CommBuffer + 0x20)) - destination buffer address for the operation (if applicable)
__int64 __fastcall SmfbFunc2(__int64 a1, char *addr, unsigned __int64 *size_ptr, char *dest)
{
switch ( *(_DWORD *)gValueInitializedByUnknownProtocol1c2e4602 )
{
case 0:
return sub_800027F8((__int64)gValueInitializedByUnknownProtocol1c2e4602, addr, dest, size_ptr);// SMM memory corruption
case 1:
return sub_80002BFC( // SMM memory corruption
gValueInitializedByUnknownProtocol1c2e4602,
addr,
dest,
size_ptr,
addr);
case 3:
return sub_80003044(
gValueInitializedByUnknownProtocol1c2e4602,
addr,
dest,
size_ptr,
addr);
}
return EFI_UNSUPPORTED;
}From this point there are two ways available for corrupting SMM memory.
The first is bug located in sub_800027F8():
MACRO_EFI __fastcall sub_800027F8(__int64 val, char *addr, char *dest, unsigned __int64 *size_ptr)
{
if ( *(_DWORD *)gValueInitializedByUnknownProtocol1c2e4602 )
return EFI_UNSUPPORTED;
v8 = *((_QWORD *)gValueInitializedByUnknownProtocol1c2e4602 + 0xB);
v9 = EFI_SUCCESS;
counter = 0;
v11 = *(void **)(v8 + 0x10);
v12 = *(void **)(v8 + 8);
v16 = *(void **)(v8 + 0x10);
if ( !*size_ptr )
return v9;
while ( 1 )
{
if ( addr == dest || !CompareMemory(addr, dest, 1i64) )
goto LABEL_12;
SetMemory(v12, 1ui64, 0xAA);
SetMemory(v11, 1ui64, 0x55);
SetMemory(v12, 1ui64, 0xA0);
SetMemory(addr, 1ui64, *dest); // Write controllable byte to a controllable address
The second bug is located at sub_80002BFC():
unsigned __int64 __fastcall sub_80002BFC(__int64 val, char *addr, __int64 dest, unsigned __int64 *size_ptr, __int64 addr_copy)
{
v5 = 0;
v8 = 0;
if ( *size_ptr )
{
v9 = dest - (_QWORD)addr;
do
{
SetMemory(addr, 1, 0x40); // Write byte to a controllable address
SetMemory(addr, 1, addr[v9]); // Write byte to a controllable address
SetMemory(addr, 1, 0x70); // Write byte to a controllable address
v10 = 0i64;
while ( *addr_1 >= 0 )
{
sub_80003D5C();
v10 += 2;
if ( v10 >= 0x989680 )
{
*size_ptr = v8;
v5 = EFI_DEVICE_ERROR;
goto LABEL_7;
}
}
++v8;
++addr;
}
while ( v8 < *size_ptr );
}
LABEL_7:
SetMemory((void *)addr_copy, 1ui64, 0x50); // Write byte to a controllable address
SetMemory((void *)addr_copy, 1ui64, 0xFF); // Write byte to a controllable address
return v5;
}Because no validation is applied for the input addr argument (when invoking SmfbFunc2()), a possible attacker can make it to point into SMRAM contents. Then:- the execution flow in SmfbFunc2()->sub_800027F8() will lead to writing controllable bytes from dest to addr;- the execution flow in SmfbFunc2()->sub_80002BFC() will lead to writing fixed bytes to addr.
In case a caller specifies *((_DWORD *)CommBuffer + 6) = 1 before entering this handler, routine (*(UnknownProtocol297067C + 0x18))() will be called. It is implemented in SMM driver FwBlockServiceSmm GUID 74D936FA-D8BD-4633-B64D-6424BDD23D24, we call it as SmfbFunc3() (located at offset 0x1F20) with the same controllable arguments:
__int64 __fastcall SmfbFunc3(__int64 a1, unsigned __int64 addr, unsigned __int64 *size_ptr)
{
size = *size_ptr;
if ( *(_DWORD *)gValueInitializedByUnknownProtocol1c2e4602 )
{
if ( *(_DWORD *)gValueInitializedByUnknownProtocol1c2e4602 == 1 )
{
if ( (_WORD)size )
{
result = EFI_INVALID_PARAMETER;
}
else
{
for ( counter = *size_ptr >> 16; counter; --counter )
{
SetMemory((void *)addr_1, 1ui64, 0x20); // Write byte to a controllable address
SetMemory((void *)addr_1, 1ui64, 0xD0); // Write byte to a controllable address
SetMemory((void *)addr_1, 1ui64, 0x70); // Write byte to a controllable address
This also ends up into writing fixed bytes to addr.
The abovementioned cases lead to corrupting memory in SMRAM at a controllable address with a predictable data and size. It could be used for example to change SMI handler's code or modify SMRAM Map structures to break input pointers validation for other SMI handlers, hence to completely make this mitigation inefficient. This could lead to gaining arbitrary code execution in SMM.
This vulnerability is explotiable from the runtime.
This bug is subject to a 90 day disclosure deadline. After 90 days elapsed or a patch has been made broadly available (whichever is earlier), the bug report will become visible to the public.
Binarly REsearch Team
.svg)
