In 2021, a critical security vulnerability plagued AMD’s Secure Processor, specifically in the way it loads Trusted Applications (TAs). Tracked as CVE-2021-26391, this flaw involves insufficient verification of multiple header signatures while loading a Trusted Application (TA). Attackers with the right privileges could exploit this to execute code—potentially taking over the TA, or even parts of the system’s kernel or OS.

Let’s break down what this means, how it can be exploited, and the best ways to defend your systems.

What’s the Vulnerability?

A Trusted Application (TA) runs in a secure environment, isolated from the regular operating system. It should be almost impossible to inject malicious code into a TA, because the hardware verifies cryptographic signatures in several headers before letting the TA run.

But in some affected AMD Secure Processors, these signature checks were only partially done. This meant that if an attacker managed to get privilege inside the OS, they could sneak in a malicious TA where only some headers were legitimate, and the rest were tampered with.

Who’s Affected?

This vulnerability mainly affects systems using AMD Secure Processor (PSP, Platform Security Processor) firmware. This is found in many AMD Ryzen and EPYC chips.

If your hardware or cloud provider uses these—especially if you rely on features related to trusted execution, secure boot, or disk encryption with Secure Processor support—you’re potentially at risk.

Scenario

1. Attacker gets OS-level privileges (root/admin).

The TA is loaded by the Secure Processor, which doesn't thoroughly check all headers.

4. Malicious code runs inside the TA’s secure context—or in some cases, escalates to tamper with the OS/kernel itself.

Here’s a pseudo-code illustrating what goes wrong

// Flawed header checking during TA load

bool verify_headers(TA_Image ta) {
    if (!verify_signature(ta.primary_header)) {
        return false; // primary header check OK
    }
    // ... forgot to check all secondary headers!
    return true;
}

// Adversary's code: craft TA with valid primary, but evil code elsewhere
TA_Image evil_ta = create_ta();
evil_ta.primary_header = sign_with_AMD_key(valid_header_data);
evil_ta.secondary_header = modify_as_needed(evil_code);
upload_to_system(evil_ta);

In this example, the function skips validating all relevant headers—opening the door to attack.

Gain necessary privileges:

- The attacker must already have root/admin (non-trivial in itself).

Simple TA Crafting Snippet

with open("legit_primary_header.bin", "rb") as hdr:
    primary = hdr.read()
malicious = b"\x90" * 100  # NOP sled example, replace with real payload

with open("malicious_ta.img", "wb") as f:
    f.write(primary)
    f.write(malicious)  # Overwrite or append the secondary header!

Real-World Consequences

- Full compromise of secure world applications: Attackers could extract cryptographic keys, snoop on sensitive operations, or escalate privileges.
- Bypass of disk encryption or secure storage: If local storage encryption uses keys from Secure Processor, an attacker with physical disk access could decrypt data.
- Possible kernel takeover: Depending on how the Secure Processor is configured, escalation could take over the OS.

Mitigation & Fix

AMD released firmware updates that properly validate all related headers before loading a TA.

Make sure your AMD system or cloud provider runs the latest Secure Processor (PSP) firmware.

- Update all firmware as advised in AMD's official advisory and refer to CVE-2021-26391.

References

- CVE-2021-26391 at NVD
- AMD Security Bulletin
- Exploring TrustZone and TA attacks (general background)

Final Thoughts

CVE-2021-26391 is a big reminder: even small oversights in signature checking can undermine the fabric of hardware-backed security. If you manage AMD hardware—especially in enterprise, server, or cloud settings—take the time to confirm your updates are current and monitor who gets root access. Don't let a single unchecked header become the weakest link in your security chain.

Timeline

Published on: 11/09/2022 21:15:00 UTC
Last modified on: 11/23/2022 14:00:00 UTC