Eclypsium has discovered new vulnerabilities in a particular Unified Extensible Firmware Interface (UEFI) implementation from HP. This is the first vulnerability to be discovered automatically by our Automata binary analysis system, which replicates the tooling and techniques used by human security researchers. In addition to this vulnerability, we’ve discovered several other vulnerabilities in IT infrastructure components and are in the process of disclosing these vulnerabilities to the respective vendors. We will publish details about these vulnerabilities when it is responsible to do so—stay tuned. 

Background on UEFI

UEFI is the interface between a computer’s operating system and its firmware, and is the successor to BIOS. UEFI is a reference architecture so there are many different implementations, the first entering the market in 2004 with Intel’s open source implementation, Tiano, which has since been superseded by the current versions EDK and EDK2. In addition to adding support for larger hard drives, network boot, and modern hardware, UEFI plays a significant role in security as it is required for security controls like Secure Boot and TPM chips. As the first code which executes during system startup, and it is the foundation on which modern computing is built. UEFI plays an important role in firmware supply chain security by controlling the initialization of low-level drivers and ensuring only properly signed boot loaders are allowed to run during system startup. 

In recent years, UEFI has become an increasingly popular target for both security researchers and malicious actors as it executes before the operating system and any security tooling are active and has access to all components of the system. Backdoors like CosmicStrand and MosaicRegressor demonstrate that attackers are shifting towards low-level persistence, evading EDR and other OS-level defenses. 

Eclypsium is continuously researching and developing defenses for UEFI attacks, allowing organizations to verify the integrity of their devices. However, security is multi-layered and comprehensive security means identifying vulnerabilities, not merely detecting attacks after-the-fact. We have developed a tool, Automata, which automatically reverse-engineers UEFI binaries and scans for vulnerabilities which attackers could leverage to bypass security controls, install persistent backdoors into UEFI, or attack the operating system during boot. 

Vulnerability Details

When we reported this new vulnerability to HP, they declined to issue a CVE identifier as it is relatively low severity and affects a product model that has reached end-of-life status in September 2020, the HP ProBook 11 EE G1. These types of unreported vulnerabilities in end-of-life products pose a difficult challenge for security organizations—something that Eclypsium can help with, but more on that at the end of this blog post. 

The vulnerability is caused by an unsafe call to the GetVariable UEFI service. As its name suggests, the GetVariable service is used to retrieve the value of a variable that is stored in the firmware. These variables can hold a variety of data important for system configuration and management, including boot settings, system policies, and hardware configurations. 

When there are two calls to GetVariable with the same DataSize argument, if an attacker sets a value to the first UEFI variable with a value long enough, it can lead to a buffer overflow on the second call. This vulnerability was found present in multiple DXE drivers, and the vulnerable code we identified is shown below.

1. Binary GUID: 7E9C835A-30EA-4EE0-9FB6-C345F0B5C307  (F10ExtendedFeature)

There are two calls to GetVariable with the “SetupDefaults” name and the DataSize value could be controlled in the second call, leading to overflow of the buffer pointed to by param_1. param_1 is not null as it is referenced in the same function.

(*gRS_3->GetVariable)
     ((CHAR16*)"SetupDefaults",
     &guid_05299c28_3953_4a5f_b7d8_f6c6a7150b2a,
     (UINT32 *)0x0,&data_size,param_1);

EVar94 = (*gRS_3->GetVariable)
     ((CHAR16 *)"SetupDefaults",
     &guid_05299c28_3953_4a5f_b7d8_f6c6a7150b2a,
     (UINT32  *)0x0,&data_size,param_1
);

There are two calls to GetVariable with the “HP_CustomUrl” name and the DataSize value could be controlled in the second call, leading to overflow of the buffer pointed to by param_1. param_1 is not null and points to the stack of a parent function in at least one use of the function.

local_10 = (*gRS_3->GetVariable)
     ((CHAR16 *)"HP_CustomUrl",
     &guid_ad147fbc_3e33_4745_ae27_7644a2eb5eda,
     (UINT32 *)0x0,&data_size,param_1
);

ret_code = (*gRS_3->GetVariable)
     ((CHAR16  *)"HP_CustomUrl",
     &guid_ad147fbc_3e33_4745_ae27_7644a2eb5eda,
     (UINT32 *)0x0,&data_size,param_1);

2. Binary GUID: E3B416C5-3CA9-4740-BA08-E653AA112CB2 (HpEmbeddedControllerImplRtDxe)

There are two additional calls to GetVariable with the “HP_Setup” name and the DataSize value could be controlled in the second call, leading to a stack overflow of the buffer pointed to by p_data_buffer. The check (ret_code != 0) does not prevent the attack as the return code would be non-zero with a long enough HP_Setup UEFI variable set. p_data_buffer is not null as it is a stack buffer.

ret_code = (*gRS_0->GetVariable)
     ((CHAR16 *)"HP_Setup",
     &guid_05299c28_3954_4a5f_b7d8_f6c6a788bb2a,
     (UINT32 *)0x0,&data_size,p_data_buffer);

if ((ret_code != 0) &&
     (ret_code = (*gRS_0->GetVariable)
     ((CHAR16  *)"HP_Setup",
     &guid_05299c28_3954_4a5f_b7d8_f6c6a788bb2a,
     (UINT32 *)0x0,&data_size,p_data_buffer),
     ret_code != 0)) 
     {
     return false;
     }

3. Binary GUID: A5C6006B-8BD7-4FCA-A924-5BBF9D8BB9B9 (PeiAtaCommands)

There are two calls to GetVariable with the “HP_MAC_ADDRESS” name and the DataSize value could be controlled in the second call, leading to a pool overflow of the buffer pointed by p_data_buffer. The (ret_code == EFI_BUFFER_TOO_SMALL) check does not prevent the attack as the value is expected with a long enough HP_MAC_ADDRESS UEFI variable set. p_data_buffer is not null as it points to an allocated pool buffer.

ret_code = (*gRS_0->GetVariable)
     ((CHAR16 *)"HP_MAC_ADDRESS",
     &guid_3f02b9f8_9810_4560_9738_2394020e6fd1,
     (UINT32 *)0x0,&data_size,
     p_data_buffer);

if ((ret_code == EFI_BUFFER_TOO_SMALL) &&
     (ret_code = (*gRS_0->GetVariable)
     ((CHAR16 *)"HP_MAC_ADDRESS",
     &guid_3f02b9f8_9810_4560_9738_2394020e6fd1,
     (UINT32*)0x0,&data_size,
     p_data_buffer),
     ret_code == 0))

4. Binary GUID: 470B83AC-33C7-49B4-912C-AB4B94574E9B (MultiUser)

There are two calls to GetVariable with the “HP_BIOSAdminScanCode” and “HP_TempBIOSAdminScancode” names and the DataSize value could be controlled in the second call, leading to a stack overflow of the buffer. p_data_buffer_2 is not null as it points to the stack.

(*gRS_2->GetVariable)
     (((CHAR16 *)"HP_BIOSAdminScanCode",
     (&guid_29c59d66_f2b4_435e_9a75_e5e6e4973c22,
     ((UINT32 *)0x0,data_size,
     (p_data_buffer_1);

(*gRS_2->GetVariable)
     (((CHAR16 *)"HP_TempBIOSAdminScancode",
     (&guid_29c59d66_f2b4_435e_9a75_e5e6e4973c223,
     ((UINT32 *)0x0,
     (data_size,p_data_buffer_2);

Mitigation

There is no remediation available for this particular vulnerability as the affected product model (HP ProBook 11 EE G1) is no longer supported. However, Eclypsium customers can identify these systems through our platform and tag for special monitoring (see screenshots below). For example, customers can set firmware baselines for these devices to alert them of any changes which could indicate compromise. Attempted exploitation of these vulnerabilities would likely include malicious code in UEFI, changing the firmware’s baseline and triggering a detection. 

Vulnerabilities such as this in end-of-life or unsupported products are another reason why it’s important to have continuous third-party assurance for your IT infrastructure. We will continue to see attackers target UEFI and other low-level components of IT infrastructure as they seek to evade detection and maintain persistence. 

Eclypsium Automata will continue to discover previously unreported vulnerabilities such as this one. In addition, our platform will provide continuous monitoring for your IT infrastructure at the lowest levels and helping you to protect your organization against threats to your digital supply chain. 

To learn more, take this tour to see how Eclypsium monitors baselines [no form-fill required].

The post Automata in Action: New Vulnerabilities Discovered in HP UEFI appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

*** This is a Security Bloggers Network syndicated blog from Eclypsium | Supply Chain Security for the Modern Enterprise authored by Chris Garland. Read the original post at: https://eclypsium.com/blog/automata-in-action-new-vulnerabilities-discovered-in-hp-uefi/