CWE-1288 Improper Validation of Consistency within Input

CWE-1288 covers complex input made of several elements or fields that must be consistent with each other, where the product does not validate or incorrectly validates that they are. Binary protocol parsers, file format readers and API handlers with related fields are the usual hosts.

How it happens

MITRE's own illustration is a number-of-items field followed by the expected number of elements. Each field can look valid by itself. The input is only wrong when the fields are compared.

When such complex inputs are inconsistent, attackers can trigger unexpected errors, cause incorrect actions, or exploit latent vulnerabilities.

Three recorded cases are all different relationships.

• CVE-2018-16733: the product does not validate that a start block appears before an end block.
• CVE-2006-3790: a size field that is inconsistent with the packet size leads to a buffer over-read.
• CVE-2008-4114: a system crash with an offset value that is inconsistent with the packet size.

Vulnerable and fixed

A parser that trusts a declared length:

/* Vulnerable: length field is never compared to what arrived */
struct msg {
    uint16_t len;
    uint8_t  data[];
};

void handle(const uint8_t *pkt, size_t pkt_len) {
    const struct msg *m = (const struct msg *)pkt;
    process(m->data, m->len);   /* may read past pkt_len */
}

A version that checks the fields against each other and against reality:

/* Safer: header fits, and declared length fits the packet */
void handle(const uint8_t *pkt, size_t pkt_len) {
    if (pkt_len < sizeof(struct msg)) return;
    const struct msg *m = (const struct msg *)pkt;
    size_t declared = ntohs(m->len);
    if (declared > pkt_len - sizeof(struct msg)) return;
    process(m->data, declared);
}

The same idea in a higher level language, for an ordered range:

# Safer: check relationships between fields, not only each field
def parse_range(req):
    start = req["start"]
    end = req["end"]
    if not isinstance(start, int) or not isinstance(end, int):
        raise ValueError("start and end must be integers")
    if start < 0 or end < start:
        raise ValueError("start must not exceed end")
    return start, end

What an attacker gains

MITRE tags consequences as varying by context. The recorded cases show a buffer over-read, which can disclose memory, and crashes, which deny service. The start and end block case is a logic error that the product accepted.

How to find it

The record lists no detection methods. Practical checks:

1. List every input format with a count, size, offset, range or pair of dependent fields.
2. For each relationship, find the code that enforces it. If you cannot find any, that is a gap.
3. Test by breaking one field at a time: count too high, count too low, offset past the end, end before start.
4. Fuzz parsers with structure aware mutation, since random bytes rarely satisfy the headers deeply enough to reach the logic.

How to fix it

The record offers no mitigation text. Steps that follow from the definition:

1. Write down the consistency rules for each format, such as declared size must not exceed remaining bytes.
2. Check the rules before using any of the fields.
3. Compare declared values against the actual size of what was received.
4. Reject inconsistent input entirely. Do not trim or guess.
5. Where possible, use a parsing library or generated parser that enforces these rules for you, and keep it updated.

Quick check

Sources

• MITRE CWE-1288