Security-version number in hardware is mutable, resulting in the ability to downgrade (roll-back) the boot firmware to vulnerable code versions.
View on MITREA System-on-Chip (SoC) implements secure boot or verified boot. It might support a security version number, which prevents downgrading the current firmware to a vulnerable version. Once downgraded to a previous version, an adversary can launch exploits on the SoC and thus compromise the security of the SoC. These downgrade attacks are also referred to as roll-back attacks. The security version number must be stored securely and persistently across power-on resets. A common weakness is that the security version number is modifiable by an adversary, allowing roll-back or downgrade attacks or, under certain circumstances, preventing upgrades (i.e. Denial-of-Service on upgrades). In both cases, the SoC is in a vulnerable state.
Impact includes roll-back or downgrade to a vulnerable version of the firmware or DoS (prevent upgrades).
When architecting the system, security version data should be designated for storage in registers that are either read-only or have access controls that prevent modification by an untrusted agent.
During implementation and test, security version data should be demonstrated to be read-only and access controls should be validated.
Mutability of stored security version numbers and programming with older firmware images should be part of automated testing.
Anti-roll-back features should be reviewed as part of Architecture or Design review.
No examples or observed CVEs available for this CWE.
No relationship information available for this CWE.
CWE-1328: Security Version Number Mutable to Older Versions is a Common Weakness Enumeration (CWE) entry maintained by MITRE. Security-version number in hardware is mutable, resulting in the ability to downgrade (roll-back) the boot firmware to vulnerable code versions. A System-on-Chip (SoC) implements secure boot or verified boot. It might support a security version number, which prevents downgrading the current firmware to a vulnerable version. Once downgraded to a previous version, an adversary can launch exploits on the SoC and thus compromise the security of the SoC. These downgrade attacks are also referred to as roll-back attacks. The security version number must be stored securely and persistently across power-on resets. A common weakness is that the security version number is modifiable by an adversary, allowing roll-back or downgrade attacks or, under certain circumstances, preventing upgrades (i.e. Denial-of-Service on upgrades). In both cases, the SoC is in a vulnerable state.
If exploited, CWE-1328 (Security Version Number Mutable to Older Versions) it can compromise Confidentiality, Integrity, Authentication and Authorization, leading to outcomes such as Other.
Recommended mitigations for CWE-1328 include: When architecting the system, security version data should be designated for storage in registers that are either read-only or have access controls that prevent modification by an untrusted agent. During implementation and test, security version data should be demonstrated to be read-only and access controls should be validated.
CWE-1328 can be detected using Automated Dynamic Analysis and Architecture or Design Review. Combining automated tooling with manual review typically yields the best coverage.
CWE-1328 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.
A CWE (Common Weakness Enumeration) like CWE-1328 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.