Embedded systems are everywhere, from your smart thermostat to industrial robotic arms. Secure boot and update mechanisms are supposed to keep these devices safe from hackers. But sometimes, even the bootloader isn’t bulletproof. In late 2022, a big vulnerability was found in several NXP LPC55S6x microcontrollers. This post explores CVE-2022-22819, how the bug works, code examples of triggering the flaw, and practical steps on what attackers and defenders should know.

LPC55S69JEV98

These chips are popular in IoT, automotive, and industry because of their power efficiency and security features.

What Got Broken?

The boot ROM in these chips contains code to receive and apply firmware updates in the so-called SB2 format. Before actually checking if an update is signed and authentic, the ROM tries to parse parts of the incoming SB2 file. A bug in this parsing allows an attacker to send a malicious, unsigned update file that overflows a buffer, letting them run code of their own choosing—*before* the ROM even looks at the signature.

> Key Point: Attackers can gain non-persistent code execution via USB or UART update process by crafting a malicious SB2 file.

Parses “chunks” to figure out metadata (lengths, types in headers).

3. Copies chunk data into a fixed-size stack buffer before verifying the cryptographic signature block.
4. If chunk fields are specially crafted, data overruns the buffer, overwriting the stack, including the return address.

This is a classic buffer overflow. If the attacker knows the memory layout and CPU core (ARM Cortex-M33), they can set up a Return-Oriented Programming (ROP) chain or direct the program counter to their code in RAM.

Visual

[SB2 File] -------> [ROM Parser] --> Buffer Overflow here: [stack/heap]
                                 ^                |
                                 |<-----evil-----/

Suppose the vulnerable function is similar to

void process_sb2_header(const uint8_t* hdr, size_t len) {
    uint8_t buffer[256];
    // The bug: 'len' isn't checked properly!
    memcpy(buffer, hdr, len);
    // ...signature is checked *after* this...
}

If you make an SB2 file with len field set to something like 512, and fill the first 256 bytes with junk, then write special values into the next few bytes, you can:

Overwrite return address (Cortex-M33 = 32 bits).

- Place your shellcode (payload) in the oversized buffer, so control jumps to it when the function returns.

Gain Execution:

- If the microcontroller is in ISP (In-System Programming) mode, the boot ROM will parse your file, trip over the buffer, and jump into your code.

Example SB2 Chunk Layout (Pseudo-hex)

| SB2 Header | [Type=DATA][Length=x400][...payload...]
                    |
                  Overflows buffer (256 bytes) ->
                  ...overwrites return address...
                  ...places shellcode...

Non-Persistent Exploit

- The attacker’s code runs in RAM ONLY—when device reboots, it's gone (unless they escalate to flashing new firmware).

The Impact

- Physical Access Required: Attacker needs to trigger ROM’s update mode—often via a pin or jumper.
- Breaks Secure Boot Assumptions: Even if production fuses and boot protections are set, *ROM bugs* can undermine it.
- No Persistence Without Further Flaws: The code is not written to flash automatically; attacker must exploit other bugs for persistence.

Real-World Usage Scenario

1. Industrial PLC with Locked Firmware: The owner locked firmware updates with cryptographic signatures, thinking the device is safe.
2. Malicious Technician: Attacker with brief physical access boots the device into update mode, pushes malicious SB2 payload, *instantly* extracts cryptographic keys from RAM, or disables security via code injection.
3. Device Returns to Original Firmware: After reset, all traces are gone—no sign in logs or storage.

Official NXP Security Advisory:

NXP Doc (Doc Number: LPC55S6x_ROM_Firmware_Update_Security_Advisory)

CVE Details:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22819

NXP Community Bug Response:

https://community.nxp.com/t5/LPC-Microcontrollers/Boot-ROM-vulnerability-LPC55S69/m-p/1406396

Sample SB2 Parsing Code (NXP MCUBoot):

https://github.com/NXPmicro/mcuboot/blob/main/boot/bootutil/src/loader.c

What Can You Do?

Vendors:
- Devices with ROM version 1B are *not patchable* in the field! Hardware must be replaced to fully fix.
- NXP changed ROM in later production runs and provided mitigations for some use-cases (e.g., lock debug access, use physical tamper pins).

Developers:

Don’t trust *any* code, even microcontroller ROM.

- Minimize exposure of debug/update modes.

End Users:
- Physically secure devices. Restrict access to debug/update connectors.
- Assume attackers with physical access to locked-down devices can cause limited, temporary mischief—even with “unhackable” chips.

Conclusion

CVE-2022-22819 proves that even the most basic, “unpatchable” pieces of code—microcontroller ROM—can hide dangerous critical bugs. While this exploit needs hands-on access, it’s a sobering reminder for hardware designers and security engineers. Even top brands and “secure” architectures can have flaws under the surface. Security is never “set-and-forget”—it’s a process.

Timeline

Published on: 03/23/2022 22:15:00 UTC
Last modified on: 04/15/2022 18:16:00 UTC