Overview
Vendor-signed UEFI Shell applications may allow an attacker to bypass Secure Boot protections by abusing commands such as mm (Memory Modify). On systems that trust the affected vendor’s certificate or include the application’s Authenticode hash in the UEFI Authorized Signature Database (DB), an attacker with sufficient access could use the application’s direct memory-access capabilities to disable or circumvent Secure Boot enforcement and execute untrusted UEFI code. To mitigate this risk, system administrators should apply available firmware and software updates from affected hardware vendors.
Description
The Unified Extensible Firmware Interface (UEFI) standard defines the firmware architecture used to initialize hardware and transfer control to modern operating systems during system startup. On systems with Secure Boot enabled, UEFI applications and drivers must be cryptographically signed and verified before their execution. Trust for these signatures is managed through several databases, including the Authorized Signature Database (DB), which commonly contains certificates from original equipment manufacturer (OEM) vendors, operating system authorities, and other supply-chain partners in the UEFI ecosystem.
There are multiple implementations of the UEFI Shell, and OEM vendors typically sign the implementation that they distribute. Some UEFI Shell implementations expose built-in capabilities for directly manipulating system memory and interacting with the UEFI environment. Because the Shell is vendor-signed and therefore permitted to execute with Secure Boot enabled, an attacker who can launch a vulnerable Shell can use these capabilities to modify the protected pre-boot state and potentially load or execute untrusted UEFI code. This creates a security boundary violation: Secure Boot permits execution of the signed Shell, while the Shell itself provides the primitives necessary to circumvent the integrity protections Secure Boot is intended to enforce. As a result, an attacker can potentially compromise the pre-boot environment despite Secure Boot being enabled.
Researchers from Binarly identified multiple UEFI Shell applications vulnerable to this type of abuse. Note that Eclypsium has also identified and reported some such signed UEFI shell binaries that expose high-privileged capabilities that can be used to bypass Secure Boot. To neutralize the risk, the affected binaries will need to be added to vendor-specific DBX revocation lists to prevent them from executing on the target systems.
| Impacted UEFI Applications [Vendor, Application and vulnerable function Authenticode SHA hash SHA256 file hash] |
|---|
Acer `UEFI shell` mm,dmpstore 805f72afd179fe67ceee14c76f92c8f76cad23130fa075d1d5678e242a0d3d52 f52b8dbffaa9b57910b3c369c384f7ccfe8d696e05e7a8a7f0da0db5540949c2 |
Acer `UEFI shell` mm,dmpstore b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883 b3a999b7fad3c8cfeff88ab8b29d261b241689c857e13414a9ae0e9f84a10a5f |
Acer `UEFI shell` mm,dmpstore a249bd3044e9aa5d4e2dfa9f94b0ffa437f4ebf3f39d57c9f276b3b9988b2b0b 77a36a8f035dfb1fdf5170f396e29a8b3e4b93558317a51eafd5be9c5ead5ef9 |
Acer `UEFI shell` mm,dmpstore 6ce33e23b21bfa1ce143fdadf55d00340a9fa3215dd73e31fa6307d5733b8841 77019c81bdc1accbd0c99b20b12edcd578dabc4cac4fa66934465f20c1c0aa2c |
Acer `UEFI shell` mm,dmpstore ad30615c1ad7da2e47dcf28a571dc62b9c034c6ade434de8daa35965062f3a7f c0194c555db9f5f7080c3344db028f44af522bac63c13d764ff416ac244e3c08 |
Acer `UEFI shell` mm,dmpstore b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883 b2e0afb2844241479db7d19398c837049fb4c7f08560963d616b3c95b1d382e2 |
Dell `UEFI shell` mm,dmpstore 3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7 2bfbec41b536b248a3e0a28dddfbcd57f774f03b72028cec91def28b2dcffc2f |
Dell `UEFI shell` mm,dmpstore 3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7 5cdf3d75c0ec0800b9692aedef19527f06eb4a16fdda586f5527350e2f6a40ad |
Dell `UEFI shell` mm,dmpstore 3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7 6ccd1ee8b067d02c083e73a0c2e18712d55b78bd99fec392daf702a147ce6d41 |
Dell `UEFI shell` mm,dmpstore 3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7 a632de93bfd10d89326db2171673bd246cd6533dcdf8e5f6de85949855695e78 |
Dell `UEFI shell` mm,dmpstore 113a80eac88190d96832cd50c9ea8de3bd6e08d8bcae2e6cea738eb73f64c5d7 d2ed7a747c5b3e5c83319e5d186ec602918fbf0651d059699a3c68f609d25cf2 |
Dell `UEFI shell` mm,dmpstore 3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7 ec23a874c3c0e852becc8fa4010c60e5f8922fe671f5351cf8a976da59a01f86 |
Dell `UEFI shell` mm,dmpstore 3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7 f75456cd23e492a078b3a81ffbbe262a1511ac9480c4f397e3d4be3b4ce5a455 |
Dell `UEFI shell` mm,dmpstore 113a80eac88190d96832cd50c9ea8de3bd6e08d8bcae2e6cea738eb73f64c5d7 f89cdf53d55d70fea31723f52d6b816937aebe2a2212ddcde7e3732e39c1fbfe |
Dell `UEFI shell` mm,dmpstore 3789ca5b6ccd21a528374f0fb85958516966db9331ca68923577352b0a4b45b7 fb68dfe907b99c23e97f98518d5e1079312d3981df036bb64d4682fe6fff83b5 |
Dell `UEFI shell` mm,dmpstore b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883 20cca70af9e3b4e5640d52840c84a1968d5be6ca881b393bc236f8d349c225ce |
Dell `UEFI shell` mm,dmpstore b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883 d4e7b11a30edd1f89c4fa1664eff98907202f15bc59c2cdfddf345a09ffbb1d4 |
Eurosoft `UEFI shell` mm,dmpstore e9d873cbcede3634e0a4b3644b51e1c8a0a048272992c738513ebc96cd3e3360 1e918f170a796b4b0b1400bb9bdae75be1cf86705c2d0fc8fb9dd0c5016b933b |
Framework `UEFI shell` mm,dmpstore 2944da098861619e21b522a642235bb2ec189ff20ef96e100b2ffdd9a39c3416 51401e93b940dec1a4391303fb6e390194b90113a8f7da6e711253c82a02b8e4 |
Framework `UEFI shell` mm,dmpstore 2944da098861619e21b522a642235bb2ec189ff20ef96e100b2ffdd9a39c3416 7e1dbf3e72b8c3c4967364f49da0cd5e3c09d921086d60ac2a493b55818cd7cf |
Framework `UEFI shell` mm,dmpstore 665b26ad26c1d739720a2793acaefbd8b6c16a599b48dcdbf594640522744483 0e03ff927005c70636273a4b9287683a821082f952dc7c9beda1a4fc911dddce |
Getac `UEFI shell` mm,dmpstore 09d895bb03bdac3188ef61b09ab72b99492cfd0b785cbc3eb2eb75657a2f9fa0 380a387b53a0ca586fe32eb1459b036f5dc178b26b2b0ec618c598eb4714d1fe |
Lenovo `UEFI shell` mm,dmpstore b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883 1f2c450bbf287e35747561723079c166aed3eddfc509b26c18dd8e19417f1838 |
MinisForum `UEFI shell` mm,dmpstore 5e7b3650103fb1c15e610e2381351d9b36546f260284535ed5774adf7532f633 9de8a0194052063ce541b34fbd451071ea3051914fc234b6d691d006f0a0f994 |
Msi `UEFI shell` mm,dmpstore 61ee9a23c366a102ceb34c78af7816413769791658cdb668b02cb81ec94f7c70 da5f4aa2008e6e26c3553b3dee4cf835ceac88820658693704cea35f62733ce3 |
Seagate `UEFI shell` mm,dmpstore 665b26ad26c1d739720a2793acaefbd8b6c16a599b48dcdbf594640522744483 53d87f3b7729fe82b47606a85e606c30d2bb61d3da3f01caef17eb7164bca261 |
Uniwill `UEFI shell` mm,dmpstore 55682bec887134a2ccaa2cd5458cd3fe6395ea93bb88c9dc541806428b14fc66 d4f05110f4bb55677426067db88f61595dc1831659ba43a5770268b73d4eb479 |
Unknown `UEFI shell` mm,dmpstore 044f80d53ecea7dc108bbf54a89f431d22aa4ebd9b43da3a2abba75bede8b431 67bf47b637bff078e6eae9afbae26b82c701739ae7fcd8e7d282b1f2901f9634 |
Unknown `UEFI shell` mm,dmpstore 81da15d6acdfb7868ecea44d41c869c2295603af9a44a2d106d4c0e57d669087 8e61f24a72c3138bde4b63766ceee1ce1a70a00046cc6867c61520084d884346 |
Unknown `UEFI shell` mm,dmpstore 81da15d6acdfb7868ecea44d41c869c2295603af9a44a2d106d4c0e57d669087 88fbb6425f43eb54194dbb607141e65adc2d1e7e0d33b6bfe762504547024942 |
Impact
This vulnerability impacts systems that trust the compromised vendor certificate within their UEFI Authorized Signature Database (DB) or those that include the affected application’s Authenticode hash in the DB. An attacker with physical access or administrative privileges can leverage these trusted components to bypass Secure Boot and execute arbitrary code during the pre-boot phase. Because this execution occurs before the operating system and endpoint security products initialize, the malicious code can achieve persistent platform compromise, including the loading of unsigned kernel components, while remaining entirely invisible to standard security controls and Endpoint Detection and Response (EDR) solutions.
Solution
Apply the latest firmware and software updates from your hardware vendor. These updates are expected to replace vulnerable UEFI applications with secure versions. Update and verify the UEFI DBX on the affected systems to revoke trust in vulnerable binaries or, where necessary, the certificates used to sign them, preventing the affected binaries from executing during boot.
Acknowledgements
Thanks to Binarly for researching and reporting this vulnerability. Thanks to Eclypsium researchers continued work on UEFI risks from such signed applications. This document was written by Vijay Sarvepalli.
Recent Posts
-
VU#738147: Vendor-signed UEFI Shell applications allow Secure Boot bypass
-
VU#280377: Dokploy is vulnerable to OS command injection
-
VU#369093: MLflow dspy and statsmodels flavors bypass pickle deserialization control
-
VU#212479: Sentry Seer vulnerability allows attacker-controlled input to be executed in a privileged environment
-
VU#369611: ExLlamaV3 contains Denial of Service vulnerability via insufficient bounds checking on kernel dispatch index