Dell BOSS-N1 S-MCU Firmware Integrity and Cryptographic Verification Bypass

# Finding 1 - Unauthorized Control over S-MCU Firmware Update Process Leads to Bypassing iDRAC Cryptographic Verification ### Summary An attacker with access to the I2C/SMBus interface (such as from a compromised iDRAC) can exploit the S-MCU firmware update procedure to reprogram the controller. The S-MCU currently relies solely on checksums for verification and lacks cryptographic authentication of its own firmware. By modifying the S-MCU firmware, and recalculating the checksum an attacker can redirect SPI read requests from the iDRAC to an inactive firmware slot containing unmodified code. This allows the malicious firmware to persist in the active slot while the iDRAC incorrectly validates the clean firmware, bypassing the root-of-trust verification. This vulnerability results in the BMC being redirected to read and verify a separate memory address than the running firmware of the BOSS storage controller. This relies on vulnerability F02 to leverage the debugging interface to obtain a clear-text version of the firmware or directly manipulating the SMCU firmware, and F03 to circumvent the checksum check on the modified firmware by the controller. We leveraged F02 and F03 to demonstrate an end-to-end exploitation of the iDRAC cryptographic verification of the BOSS controller. | Attack Vector: | Physical, Compromised iDRAC (Local/I2C) | | :---- | :---- | | **Affected Products:** | **Dell BOSS-N1 S-MCU** | | **Affected Versions:** | Any firmware version | | **Severity:** | **High \- 7.3 CVSS:4.0/AV:P/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H** | |**CVE ID:**| **CVE-2026-80357**| ### Severity High - Based on a Physical Attack Vector (AV:P), as the attacker requires access to the internal I2C bus, or requires a prior compromise of the iDRAC. The attack complexity is High (AC:H) and the Scope is Changed (S:C) because compromising the S-MCU allows for the spoofing of the cryptographic verification process, effectively undermining the security guarantees of the iDRAC root of trust. ### Proof of Concept An attacker can use the I2C S-MCU firmware update procedure to redirect the I2C to SPI read requests to an inactive slot (addressed by adding 0×800000 to every read). This causes the iDRAC to validate a previous firmware update, not the firmware in the active slot that was modified previously.&nbsp; #### S-MCU Patch&nbsp; A small patch allowed for the address change by optimizing the ARM instructions, setting the addresses to free up 2-bytes and using those two bytes to add 0×80 to the high byte, which redirects iDRAC. Afterward the checksum is recalculated based on these changes. As seen below:&nbsp; <img width="686" height="227" alt="image" src="https://github.com/user-attachments/assets/feeb320e-e461-4810-9282-d1df1104bc6a" /> Modified to: <img width="667" height="219" alt="image" src="https://github.com/user-attachments/assets/34daa770-e24c-46ab-9bcc-4d7a93542ef0" /> Script to recalculate the checksum: ```python #!/usr/bin/env python3 import argparse import sys from dataclasses import dataclass from pathlib import Path FLASH_SIZE = 0x8000 SLOT_METADATA_BASE = 0x7FC0 SLOT_STRIDE = 0x40 SLOT_COUNT = 2 CHECKSUM_OFFSET = 0x00 ENTRY_POINT_OFFSET = 0x01 START_SECTOR_OFFSET = 0x05 SIZE_OFFSET = 0x09 PAGE_CKSUM_LO_OFFSET = 0x10 PAGE_CKSUM_HI_OFFSET = 0x11 def read_u16_le(data: bytes, offset: int) -> int: return int.from_bytes(data[offset : offset + 2], "little") def read_u32_le(data: bytes, offset: int) -> int: return int.from_bytes(data[offset : offset + 4], "little") @dataclass class SlotMetadata: slot: int metadata_offset: int checksum: int entry_point: int start_sector: int size: int page_checksum: int @property def image_start(self) -> int: return (self.start_sector + 1) << 7 @property def image_end(self) -> int: return self.image_start + self.size d

Severity from

GitHub (reviewed advisory)

• github.com/google/security-research/security/advisories/GHSA-wcfm-jp7m-rffh
• github.com/google/security-research