Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This compliant solution defines the acceptable range for length as [1, MAX_TABLE_LENGTH]. The length parameter is declared as size_t, which is unsigned by definition. Consequently, it is not necessary to check length for negative values . (See see INT01-C. Use rsize_t or size_t for all integer values representing the size of an object).)

Code Block
bgColor#ccccff
langc
enum { MAX_TABLE_LENGTH = 256 };

char** create_table(void) {
  const char* const lenstr = getenv("TABLE_SIZE");
  const size_t length = lenstr ? strtoul(lenstr, NULL, 10) : 0;

  if (length == 0 || length > MAX_TABLE_LENGTH)
    return NULL;   /* Indicate error to caller */

  const size_t table_size = length * sizeof(char *);
  char** const table = (char **)malloc(table_size);

  if (table == NULL)
    return NULL;   /* Indicate error to caller */

  /* Initialize table... */
  return table;
}

...

Code Block
bgColor#ccccff
langc
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)

CERT vulnerability 720951 describes a vulnerability in OpenSSL versions 1.0.1 through 1.0.1f, popularly known as "Heartbleed." . This vulnerability allows a malicious packet fed to a server using OpenSSL to trick that server into returning up to 64 kilobytes of its internal memory. This memory can contain sensitive information, including cryptographic keys, usernames and passwords.an attacker to steal information that under normal conditions would be protected by Secure Socket Layer/Transport Layer Security (SSL/TLS) encryption.

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 codeThe vulnerable code appears below:


Code Block
bgColor#ffcccc
langc
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 ... */
}

This code processes a '"heartbeat' " packet from a client. As specified in in RFC 6520, when the program receives a heartbeat packet, it must echo the packet's data back to the client. In addition to the data, the packet contains a length field that conventionally indicates the number of bytes in the packet data, but there is nothing to prevent a malicious packet from lying about its data length.

The The p pointer pointer, along with with payload and  and p1 contain , contain data from a packet. The code allocates a buffer sufficient sufficient to contain contain payload bytes bytes, with some overhead, and copies then copies payload bytes bytes starting at at p1 into into this buffer , and sends it to the client. Notably absent from this code are any checks that payload actually indicates the correct that the payload integer variable extracted from the heartbeat packet corresponds to the size of the memorypacket data. Because an attacker the client can specify an arbitrary value for of payload, she an attacker can cause this routine the server to read and return the contents of memory beyond the block allocated to p. In this case, the call to memcpy() would also violate 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
bgColor#ccccff
langc
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

Low

High

Probable

High

P2

L3

P6

L2

Automated Detection

Tool

Version

Checker

Description

Astrée
Include Page
Astrée_V
Astrée_V

Supported by taint analysis
CodeSonar
Include Page
CodeSonar_V
CodeSonar_V

IO.TAINT.SIZE
LANG.MEM.TBA
IO.TAINT.ADDR
IO.UT.HOST
IO.UT.PORT

(general)

Tainted allocation size
Tainted buffer access
Tainted network address
Untrusted Network Host
Untrusted Network Port

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

Include Page
Helix QAC_V
Helix QAC_V

DF2794, DF2804, DF2854, DF2859, DF2864, DF2894, DF2899, DF2904, DF2909, DF2914, DF2924, DF2944, DF2949, DF2954, DF2956, DF2959


Klocwork
Include Page
Klocwork_V
Klocwork_V
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
Include Page
Parasoft_V
Parasoft_V

CERT_C-INT04-a
CERT_C-INT04-b
CERT_C-INT04-c

Protect against integer overflow/underflow from tainted data
Avoid buffer read overflow from tainted data
Avoid buffer write overflow from tainted data

Polyspace Bug Finder

Include Page
Polyspace Bug Finder_V
Polyspace Bug Finder_V

CERT C: Rec. INT04-C


Checks for:

  • Array access with tainted index
  • Loop bounded with tainted value
  • Memory allocation with tainted size
  • Tainted size of variable length array

Rec. partially supported.

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

SEI CERT C++
Secure
Coding StandardVOID INT04-CPP. Enforce limits on integer values originating from untrusted sources
ISO/IEC TS 17961:2013Forming 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"

 


...

Image Modified Image Modified Image Modified