CWE-349, Acceptance of Extraneous Untrusted Data With Trusted Data, describes a product that accepts any untrusted data included alongside trusted data and treats all of it as trusted.
It is a risk wherever data arrives wrapped in some form of endorsement: signed documents, certificates, DNS responses, authenticated envelopes.
How it happens
A system verifies something and gets a yes. From that moment the whole object is treated as vouched for. But verification often covers only part of the object. The rest, extra fields, trailing bytes, additional records, never had a guarantor.
MITRE's observed examples show two shapes. CVE-2002-0018 describes a case where the product does not verify that a trusted entity is authoritative for all entities in its response. The trusted party answered for one thing, and the product believed the extras too. CVE-2006-5462 describes extra data in a signature being used to forge a certificate signature.
What an attacker gains
The record lists bypass of protection mechanisms and modification of application data. An attacker packages their own content with legitimate content and lets the trusted part carry the rest through the checks.
How to find it
The record lists no detection methods. Use these checks in review.
- After a verification step, what exactly was verified? Name the bytes or fields.
- Does the code use anything beyond that verified portion?
- Are unknown or extra fields rejected, or silently accepted?
- If a response contains records about several entities, does the code confirm the sender is authoritative for each?
How to fix it
MITRE lists no mitigations for this entry. These steps come from the definition.
- Use only the data that the verification covered, and discard or reject the rest.
- Parse strictly. Unexpected trailing data and unknown fields should fail the parse.
- Verify authority per item, not per message.
- Re-derive what you need from the verified portion rather than from the original unverified wrapper.
A simple way to think about it: the result of a check should be a new, smaller object containing only what passed.
def accept(message):
if not verify_signature(message.payload, message.signature):
raise ValueError("bad signature")
# Use only the signed payload, never other fields on message
return parse_strict(message.payload)
The code returns the parsed signed payload. It never reads anything else off the message.
Quick check
What does CVE-2006-5462 show about this weakness?
Extra data included in a signature was used to forge a certificate signature, so data that was never vouched for was treated as if it had been.
Sources
- MITRE CWE-349: https://cwe.mitre.org/data/definitions/349.html
