...
Code Block | ||||
---|---|---|---|---|
| ||||
enum { MAX_COLOR_INDEX = 3 }; const char *table[] = { "black", "white", "blue", "green" }; const char *set_background_color(void) { int color_index; GET_TAINTED_INTEGER(int, color_index); if (color_index < 0 || colo_index > MAX_COLOR_INDEX) return NULL; /* Indicate error to caller */ const char *color = table[color_index]; /* ... */ return color; } |
The test for length == 0
ensures that a nonzero number of bytes is allocated. (See MEM04-C. Beware of zero-length allocations.)
Noncompliant Code Example (Heartbleed)
...
Despite the seriousness of the vulnerability, Heartbleed is the result of a common programming error and an apparent lack of awareness of secure coding principles. Following is the vulnerable code:
Code Block | ||||
---|---|---|---|---|
| ||||
int dtls1_process_heartbeat(SSL *s) { unsigned char *p = &s->s3->rrec.data[0], *pl; unsigned short hbtype; unsigned int payload; unsigned int padding = 16; /* Use minimum padding */ /* Read type and payload length first */ hbtype = *p++; n2s(p, payload); pl = p; /* ... More code ... */ if (hbtype == TLS1_HB_REQUEST) { unsigned char *buffer, *bp; int r; /* Allocate memory for the response, size is 1 byte * message type, plus 2 bytes payload length, plus * payload, plus padding */ buffer = OPENSSL_malloc(1 + 2 + payload + padding); bp = buffer; /* Enter response type, length and copy payload */ *bp++ = TLS1_HB_RESPONSE; s2n(payload, bp); memcpy(bp, pl, payload); /* ... More code ... */ } /* ... More code ... */ } |
...
The p
pointer, along with payload
and p1
, contain data from a packet. The code allocates a buffer
sufficient to contain payload
bytes, with some overhead, then copies payload
bytes starting at p1
into this buffer and sends it to the client. Notably absent from this code are any checks that the payload integer variable extracted from the heartbeat packet corresponds to the size of the packet data. Because the client can specify an arbitrary value of payload
, an attacker can cause the server to read and return the contents of memory beyond the end of the packet data, which violates INT04-C. Enforce limits on integer values originating from tainted sources. The resulting call to memcpy()
can then copy the contents of memory past the end of the packet data and the packet itself, potentially exposing sensitive data to the attacker. This call to memcpy()
violates ARR38-C. Guarantee that library functions do not form invalid pointers. A version of ARR38-C also appears in ISO/IEC TS 17961:2013, "Forming invalid pointers by library functions [libptr]." This rule would require a conforming analyzer to diagnose the Heartbleed vulnerability.
Compliant Solution (Heartbleed)
OpenSSL version 1.0.1g contains the following patch, which guarantees that payload
is within a valid range. The range is limited by the size of the input record.
Code Block | ||||
---|---|---|---|---|
| ||||
int dtls1_process_heartbeat(SSL *s) { unsigned char *p = &s->s3->rrec.data[0], *pl; unsigned short hbtype; unsigned int payload; unsigned int padding = 16; /* Use minimum padding */ /* ... More code ... */ /* Read type and payload length first */ if (1 + 2 + 16 > s->s3->rrec.length) return 0; /* silently discard */ hbtype = *p++; n2s(p, payload); if (1 + 2 + payload + 16 > s->s3->rrec.length) return 0; /* silently discard per RFC 6520 */ pl = p; /* ... More code ... */ if (hbtype == TLS1_HB_REQUEST) { unsigned char *buffer, *bp; int r; /* Allocate memory for the response, size is 1 byte * message type, plus 2 bytes payload length, plus * payload, plus padding */ buffer = OPENSSL_malloc(1 + 2 + payload + padding); bp = buffer; /* Enter response type, length and copy payload */ *bp++ = TLS1_HB_RESPONSE; s2n(payload, bp); memcpy(bp, pl, payload); /* ... More code ... */ } /* ... More code ... */ } |
Risk Assessment
Failing to enforce the limits on integer values can result in a denial-of-service attack, unauthorized disclosure of information, or to run arbitrary code.
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
INT04-C |
High | Probable | High |
P2
P6 | L2 |
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Astrée |
| Supported by taint analysis | |||||||
CodeSonar |
| IO.TAINT.SIZE (general) | Tainted allocation size CodeSonar will track the tainted value, along with any limits applied to it, and flag any problems caused by underconstraint. Warnings of a wide range of classes may be triggered, including tainted allocation size, buffer overrun, and division by zero | ||||||
Helix QAC |
| DF2794, DF2804, DF2854, DF2859, DF2864, DF2894, DF2899, DF2904, DF2909, DF2914, DF2924, DF2944, DF2949, DF2954, DF2956, DF2959 | |||||||
Klocwork |
| SV.TAINTED.ALLOC_SIZE SV.TAINTED.BINOP SV.TAINTED.CALL.BINOP SV.TAINTED.CALL.INDEX_ACCESS SV.TAINTED.CALL.LOOP_BOUND SV.TAINTED.INDEX_ACCESS SV.TAINTED.LOOP_BOUND | |||||||
Parasoft C/C++test |
| CERT_C-INT04-a | Protect against integer overflow/underflow from tainted data | ||||||
Polyspace Bug Finder |
| Checks for:
Rec. partially supported. |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
SEI CERT C++ |
Coding Standard | VOID INT04-CPP. Enforce limits on integer values originating from untrusted sources |
ISO/IEC TS 17961:2013 | Forming invalid pointers by library functions [libptr] Tainted, potentially mutilated, or out-of-domain integer values are used in a restricted sink [taintsink] |
Bibliography
[Seacord 2013] | Chapter 5, "Integer Security" |
...