[BRLY-2023-002] SMM memory corruption vulnerability in SMM driver (SMRAM write)

Summary

Binarly REsearch Team has discovered a stack buffer overflow vulnerability that allows an attacker to execute arbitrary code.

Vulnerability Information

• BINARLY internal vulnerability identifier: BRLY-2023-002
• Insyde/Lenovo PSIRT assigned CVE identifier: CVE-2023-39281
• CVSS v3.1 Score 8.2 High AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

Affected Lenovo firmwares with confirmed impact by Binarly team

Potential impact

An attacker with local privileged access can exploit this vulnerability to elevate privileges from ring 3 or ring 0 (depends on the operating system) to a DXE driver and execute an arbitrary code. A malicious code installed as a result of the vulnerability exploitation in a DXE driver could survive across an operating system (OS) boot process and runtime or modify NVRAM area on SPI flash storage (to gain persistence on target platform). Additionally, this vulnerability potentially could be used by threat actors to bypass OS security mechanisms (modify privileged memory or runtime variables), influence on the OS boot process, and in some cases would allow an attacker to hook or modify EFI Runtime services.

Vulnerability description

The pseudocode of the vulnerable function is shown below (located at offset 0x520):

__int64 __fastcall AsfSecureBootChanged(EFI_EVENT Event)
{
  // [COLLAPSED LOCAL DECLARATIONS. PRESS KEYPAD CTRL-"+" TO EXPAND]

  EfiAmtWrapperProtocol = 0;
  Size = 561;
  Status = gBS->LocateProtocol(&EFI_AMT_WRAPPER_PROTOCOL_GUID, 0, &EfiAmtWrapperProtocol);
  Result = Status;
  if ( Status >= 0 )
  {
    gBS->CloseEvent(Event);
    Status = gBS->LocateProtocol(&EFI_NON_VOLATILE_VARIABLE_PROTOCOL_GUID, 0, &EfiNonVolatileVariableProtocol);
    Result = Status;
    if ( Status >= 0 )
    {
      Status = gBS->LocateProtocol(&EFI_SMM_COMMUNICATION_PROTOCOL_GUID, 0, &EfiSmmCommunicationProtocol);
      Result = Status;
      if ( Status >= 0 )
      {
        Status = (*EfiNonVolatileVariableProtocol)(&CommBuffer, &CommSize);
        Result = Status;
        if ( Status >= 0 )
        {
          Status = Size;
          if ( CommSize >= Size )
          {
            Status = gBS->LocateProtocol(&EDKII_VARIABLE_LOCK_PROTOCOL_GUID, 0, &EdkiiVariableLockProtocol);
            Result = Status;
            if ( Status >= 0 )
            {
              Result = EdkiiVariableLockProtocol->RequestToLock(
                         EdkiiVariableLockProtocol,
                         L"AsfSecureBoot",
                         &ASF_SECURE_BOOT_VARIABLE_GUID);
              DataSize = 1;
              Result = CommonGetVariable(L"AsfSecureBoot", &ASF_SECURE_BOOT_VARIABLE_GUID, &DataSize, Data);
              Status = EFI_BUFFER_TOO_SMALL;
              if ( Result == EFI_BUFFER_TOO_SMALL )
              {
                Status = CommonGetVariable(L"AsfSecureBoot", &ASF_SECURE_BOOT_VARIABLE_GUID, &DataSize, Data);
                Result = Status;
              }
              if ( !Result )
              {
                // ...
              }
            }
          }
        }
      }
    }
  }
  return Status;
}

Let's take a closer look to the following code snippet:

Result = EdkiiVariableLockProtocol->RequestToLock(
            EdkiiVariableLockProtocol,
            L"AsfSecureBoot",
            &ASF_SECURE_BOOT_VARIABLE_GUID);
DataSize = 1;
Result = CommonGetVariable(L"AsfSecureBoot", &ASF_SECURE_BOOT_VARIABLE_GUID, &DataSize, Data);
Status = EFI_BUFFER_TOO_SMALL;
if ( Result == EFI_BUFFER_TOO_SMALL )
{
  Status = CommonGetVariable(L"AsfSecureBoot", &ASF_SECURE_BOOT_VARIABLE_GUID, &DataSize, Data);
  Result = Status;
}

As we can see after the first call to CommonGetVariable() DataSize will be re-initialized if the actual size of the AsfSecureBoot variable is more then 1 byte. In this case after the second call to CommonGetVariable() stack overflow may occur.

Attacker is able to rewrite return address of the current function or EfiSmmCommunicationProtocol. This will result in executing an arbitrary code during the DXE phase.

-0000000000000068 Data            db 8 dup(?)
...
-0000000000000030 EfiSmmCommunicationProtocol dq ?        ; offset
...
+0000000000000000  r              db 8 dup(?)

In order to fix this vulnerability, it is necessary to allocate memory for the value of the AsfSecureBoot variable after the DataSize update.

It should be noted that the AsfSecureBoot variable is write protected (locked). However, an attacker can change its value from runtime using a special IHISI service (VatsWrite). This is a separate security issue which will be reported within a separate advisory.

Disclosure timeline

This vulnerability is subject to a 90 day disclosure deadline. After 90 days elapsed or a patch has been made broadly available (whichever is earlier), the vulnerability report will become visible to the public.

Acknowledgements

Binarly REsearch Team

‍