Binarly Finds Six High Severity Firmware Vulnerabilities in HP Enterprise Devices

**Unfortunately, at the time of writing, some HP enterprise devices have still not received updates to patch the aforementioned vulnerabilities, despite them being publicly disclosed for over a month. **

The Binarly security research team has had a busy year finding, documenting and helping to fix high-impact vulnerabilities affecting multiple enterprise vendors. In this blog, we provide an in-depth look at some of the vulnerabilities we discussed at the Black Hat 2022 conference affecting HP EliteBook devices.

In all, Binarly helped to fix six high-severity vulnerabilities that not only affect these devices, but were also found in multiple additional HP product lines. This disclosure was coordinated with the HP PSIRT team (HPSBHF03806) and documents arbitrary code execution vulnerabilities related to System Management Mode (SMM).

In a previous blog, we discussed the post-exploitation impact that firmware vulnerabilities can lead to, such as long-time persistence on a device. A firmware implant is the final goal for an attacker to maintain persistence. The attacker can install the malicious implant on different levels of the firmware, either as a modified legitimate module or a standalone driver. The impact of targeting unprivileged non-SMM DXE runtime drivers or applications by a threat actor is often underestimated. This kind of malicious DXE driver can bypass Secure Boot and influence further boot stages.

In addition, some vulnerabilities in SMI handlers cannot be exploited from the OS (the handler can be unregistered before the OS boot). An attacker capable of executing code in the DXE phase could exploit such vulnerabilities to escalate privileges to SMM (ring -2) if the code is executed in the time interval between the SMI handler registration and unregistration.

Earlier this year, we disclosed 16 high-severity HP-related vulnerabilities. Through this disclosure, we revealed failures related to both supply chain complexity and firmware update delivery.

In many cases firmware is a single point of failure between all the layers of the supply chain and the endpoint customer device.

Unfortunately, at the time of writing, some HP enterprise devices (laptops and desktops) have still not received updates to patch the aforementioned vulnerabilities, despite them being publicly disclosed for over a month. As shown below, Binarly’s FwHunt integration with LVFS makes these failures visible.

Based on the Binarly’s telemetry data, we are experiencing the same effect. In terms of impact at scale, firmware supply chain problems are one of the major challenges.

Approximately 20% of firmware updates contain at least two or three known vulnerabilities (previously disclosed), according to Binarly Platform data (based on enterprise-grade vendors study).

BRLY-2022-010/CVE-2022-23930 (CWE-121: Stack-based Buffer Overflow)

A lack of sanitization of the CommBuffer data allows an attacker to write any controlled data buffer and lead to arbitrary code execution in SMM. The figure below shows the vulnerable primitive.

BRLY-2022-011/CVE-2022-31644 (CWE-787: Out-of-bounds Write)

There are two nested pointers in a Communication Buffer passed into the SMI handler presented below: a pointer to a buffer and a pointer to its size. Both pointers are validated that they are pointing into the SMRAM. However, the size of the buffer (which is used for the validation) is not used further and it is not checked to be an expected value or range, which allows a possible attacker to partially bypass the applied validation for example by specifying the (QWORD )CommBuffer = SMRAM_BASE - 1 and *size_ptr = 1 byte.

As a result, an attacker can get an out-of-bounds write primitive inside the sub_24E8 function.

BRLY-2022-012/CVE-2022-31645 (CWE-787: Out-of-bounds Write)

There is a nested pointer in the Communication Buffer passed into the SMI handler below. The pointer is validated, however the size of the pointed buffer (which is used for the pointer validation) is not checked to be an expected value or range, which allows a possible attacker to partially bypass the applied validation. This  leads to a memory corruption in SMM as shown in the figure below.

BRLY-2022-013/CVE-2022-31646 (CWE-787: Out-of-bounds Write)

BRLY-2022-011, BRLY-2022-012 and BRLY-2022-013 have a similar nature of OOB write vulnerable primitives based on direct memory manipulation API functionality. Most likely, all three vulnerabilities were caused by similar coding practices applied by the firmware development team. If you look at the picture below there is a way to exploit WStringCopy() multiple times due to the lack of validation.

As a note, BRLY-2022-010, BRLY-2022-011 and BRLY-2022-013 vulnerabilities cannot be exploited directly from an operating system. An attacker capable of executing code during the DXE phase could exploit this type of vulnerability to elevate privileges to SMM and execute arbitrary code. Such out-of-bounds (OOB) write primitives are very dangerous because the vulnerable non-SMM DXE drivers are often available for exploitation from the operating system (such as BRLY-2021-005/CVE-2021-39299).

BRLY-2021-046/CVE-2022-31640 and BRLY-2021-047/CVE-2022-31641(CWE-20: Improper Input Validation)

Both BRLY-2021-046 and BRLY-2021-047 vulnerabilities are classical examples of SMM callout vulnerabilities. In terms of the vulnerable code primitives, both cases are very similar. The CommBuffer data can be controlled by an attacker and due to the lack of validation it can be modified (as shown on the figure below).  

The protocol interface EFI_PCD_PROTOCOL is located via gBS->LocateProtocol call and the SetBool() function from the protocol is executed. This shows that a potential attacker could overwrite the PcdProtocol->SetBool pointer in the EFI_PCD_PROTOCOL table with a shellcode address and trigger this handler. As a result, it leads to arbitrary code execution in SMM.

BRLY-2021-047 describes exactly the same vulnerability as BRLY-2021-046 discovered in a different module. The exploitation steps will be exactly the same as discussed above. In the figure below you can see the PcdProtocol->SetBool() (equal to Get8()) call which is controlled by an attacker, triggers the arbitrary code execution.

The majority of the vulnerabilities discussed in this blog -- and their variants -- can be proactively detected by the Binarly Platform that leverages semantic properties and apply lightweight code checkers, as discussed in our previous blog (“Using Symbolic Execution to Detect UEFI Firmware Vulnerabilities”).

FwHunt rules for the HP vulnerabilities discussed here are publicly available in Binarly’s GitHub repository, and we encourage defenders and research partners to use these rules to scope, at scale, vulnerable devices in their enterprise infrastructure. Additionally, these rules are being pushed to the Linux Vendor Firmware Service (LVFS) to enhance the supply chain security and awareness in enterprise environments worldwide.

The FwHunt detection for all the issues mentioned above related to the firmware in HP devices is shown below:

The Binarly team is constantly working to protect the firmware supply chain and reduce the attack surfaces of our customers industry-wide by delivering innovative technologies to the market. Based on our experience we understand that fixing vulnerabilities for a single vendor is not enough. As a result of the complexity of the firmware supply chain, there are gaps that are difficult to close on the manufacturing end since it involves issues beyond the control of the device vendors.

Are you interested in learning more about Binarly Platform or other solutions?Don't hesitate to contact us at [email protected].