CWE-1257 describes hardware where the same memory can be reached at several addresses and the access rules are not the same on all of them. An untrusted agent that is blocked at one address may not be blocked at the alias. Hardware and SoC designers own this problem, as do firmware engineers who write the memory protection configuration.
How it happens
Hardware designs often protect memory by letting privileged software define isolated regions with read and write policies. Regions can be defined in different spaces: system physical addresses, virtual addresses and memory-mapped I/O.
It is possible, and common, to map one memory cell to several system addresses so that a read or write to any alias reaches the same cell. Designers do it for redundancy and to simplify address decoding. If one region is faulty, the hardware can switch to the mirrored copy. Aliases can also appear as a side effect of other choices.
The failure is in the protection. MITRE's example is an SoC with a 16 bit address fabric. One unit has 4 KB of internal memory mapped into a 16 KB range. To protect the unit's registers, unprivileged software is blocked from 0x0000 to 0x0FFF. But the unit's address decoder masks off the higher address bits and decodes only the low 12 bits. The same register is therefore reachable at 0x0000, 0x1000, 0x2000 and 0x3000. The system filter blocks only the first range, so untrusted software uses an alias to bypass the protection.
What an attacker gains
The record lists high impact on confidentiality (reading memory), integrity (modifying memory) and availability (instability). An attacker who reaches protected registers through an alias can read what they should not, change it, or break the system.
How to find it
The record lists no detection methods. A design review should:
- Work out what the address decoder actually does for each unit, including which address bits it ignores.
- List every address that reaches each protected cell.
- Confirm that the protection filter covers all of them.
- Test access from an untrusted agent at each alias, not only the documented address.
How to fix it
MITRE gives two mitigations for design and implementation:
- Apply checks so access rights are consistent between the primary memory regions and any mirrored or aliased regions. If different memory protection units protect the aliased regions, synchronize their range definitions and policies.
- Make the controls that enable memory aliases or change the size of mapped regions programmable only by trusted software.
In the example, there are two fixes. Block the aliased addresses from all system software, since software does not use them, or change the protection logic so the policy covers the whole mapped range.
Quick check
How can one register have four addresses?
When the address decoder ignores higher order bits, the same low bits map to the same cell for every value of the ignored bits.
Who should be able to enable aliases?
Only trusted software components, per MITRE.
