Page History

...

Annex J of the C Standard [ISO/IEC 9899:2011] states that it is undefined behavior if the "pointer passed to a library function array parameter does not have a value such that all address computations and object accesses are valid." (see See undefined behavior 109.).

In the following code,

int arr[5];
int *p = arr;

unsigned char *p2 = (unsigned char *)arr;
unsigned char *p3 = arr + 2;
void *p4 = arr;

...

The following standard library functions take a pointer argument and a size argument, with the constraint that the pointer must point to a valid memory object of at least the number of elements indicated by the size argument.

¹ Takes two pointers and an integer, but the integer specifies the element count only of the output buffer, not of the input buffer.
² Takes two pointers and an integer, but the integer specifies the element count only of the input buffer, not of the output buffer.
³ Takes two pointers and two integers; each integer corresponds to the element count of one of the pointers.
⁴ Takes a pointer and two size-related integers; the first size-related integer parameter specifies the number of bytes available in the buffer; the second size-related integer parameter specifies the number of bytes to write within the buffer.

...

The following standard library functions take two pointer arguments and a size argument, with the constraint that both pointers must point to valid memory objects of at least the number of elements indicated by the size argument. 

For calls that take two pointers and an integer size, the given size should not be greater than the element count of either pointer.

...

The following standard library functions take a pointer argument and two size arguments, with the constraint that the pointer must point to a valid memory object containing at least as many bytes as the product of the two size arguments.

For calls that take a pointer and two integers, one integer represents the number of bytes required for an individual object, and a second integer represents the number of elements in the array. The resulting product of the two integers should not be greater than the element count of the pointer were it expressed as an unsigned char *.  

...

In this noncompliant code example, the function f() calls fread() to read nitems of type wchar_t, each size bytes in size, into an array of BUFFER_SIZE elements, wbuf. However, the expression used to compute the value of nitems fails to account for the fact that, unlike the size of char, the size of wchar_t may be greater than 1. Consequently, fread() could attempt to form pointers past the end of wbuf and use them to assign values to nonexistent elements of the array. Such an attempt is undefined behavior. (see See undefined behavior 109.).  A likely consequence of this undefined behavior is a buffer overflow. For a discussion of this programming error in the Common Weakness Enumeration database, see CWE-121, "Stack-based Buffer Overflow," and CWE-805, "Buffer Access with Incorrect Length Value."

...

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 contains 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. 

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 ... */
}

Depending on the library function called, an attacker may be able to use a heap or stack overflow vulnerability to run arbitrary code.

Automated Detection

Related Vulnerabilities

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

Related Guidelines

Related Vulnerabilities

CVE-2016-2208 results from a violation of this rule. The attacker can supply a value used to determine how much data is copied into a buffer via memcpy(), resulting in a buffer overlow of attacker-controlled data.

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

Related Guidelines

Key here (explains table format and definitions)

CERT-CWE Mapping Notes

Key here for mapping notes

CWE-121 and ARR38-C

Intersection( CWE-121, ARR38-C) =

• Stack buffer overflow from passing invalid arguments to library function

CWE-121 – ARR38-C =

• Stack buffer overflows from direct out-of-bounds write

ARR38-C – CWE-121 =

• Out-of-bounds read from passing invalid arguments to library function

• Buffer overflow on heap or data segment from passing invalid arguments to library function

CWE-119 and ARR38-C

See CWE-119 and ARR30-C

CWE-125 and ARR38-C

Independent( ARR30-C, ARR38-C, EXP39-C, INT30-C)

STR31-C = Subset( Union( ARR30-C, ARR38-C))

STR32-C = Subset( ARR38-C)

Intersection( ARR38-C, CWE-125) =

• Reading from an out-of-bounds array index or off the end of an array via standard library function

ARR38-C – CWE-125 =

• Writing to an out-of-bounds array index or off the end of an array via standard library function

CWE-125 – ARR38-C =

• Reading beyond a non-array buffer

• Reading beyond an array directly (using pointer arithmetic, or [] notation)

CWE-805 and ARR38-C

Intersection( CWE-805, ARR38-C) =

• Buffer access with incorrect length via passing invalid arguments to library function

CWE-805 – ARR38-C =

• Buffer access with incorrect length directly (such as a loop construct)

ARR38-C – CWE-805 =

• Out-of-bounds read or write that does not involve incorrect length (could use incorrect offset instead), that uses library function

CWE-123 and ARR38-C

Independent(ARR30-C, ARR38-C)

STR31-C = Subset( Union( ARR30-C, ARR38-C))

STR32-C = Subset( ARR38-C)

CWE-123 includes any operation that allows an attacker to write an arbitrary value to an arbitrary memory location. This could be accomplished via overwriting a pointer with data that refers to the address to write, then when the program writes to a pointed-to value, supplying a malicious value. Vulnerable pointer values can be corrupted by:

• Stack return address

• Buffer overflow on the heap (which typically overwrites back/next pointer values)

• Write to untrusted array index (if it is also invalid)

• Format string exploit

• Overwriting a C++ object with virtual functions (because it has a virtual pointer)

• Others?

Intersection( CWE-123, ARR38-C) =

• Buffer overflow via passing invalid arguments to library function

ARR38-C – CWE-123 =

• Buffer overflow to “harmless” memory from passing invalid arguments to library function

• Out-of-bounds read from passing invalid arguments to library function

CWE-123 – ARR38-C =

• Arbitrary writes that do not involve standard C library functions

CWE-129 and ARR38-C

ARR38-C -CWE-129 = making library functions create invalid pointers without using untrusted data.

E.g. : char[3] array;

strcpy(array, "123456");

CWE-129 - ARR38-C = not validating an integer used as an array index or in pointer arithmetic

E.g.: void foo(int i) {

  char array[3];

  array[i];

}

Intersection(ARR38-C, CWE-129) = making library functions create invalid pointers using untrusted data.

eg: void foo(int i) {

  char src[3], dest[3];

  memcpy(dest, src, i);

}

Bibliography

...

...

Image Modified Image Modified Image Modified