Page History

Many library functions accept a string or wide string argument with the constraint that the string they receive is properly null-terminated. Passing a character sequence or wide character sequence that is not null-terminated to such a function can result in accessing memory that is outside the bounds of the object. Do not pass a character sequence or wide character sequence that is not null-terminated to a library function that expects a string or wide string argument. 

Noncompliant Code Example

This code example is noncompliant because the character sequence c_str will not be null-terminated when passed as an argument to printf(). (See STR11-C. Do not specify the bound of a character array initialized with a string literal on how to properly initialize character arrays.)

#include <stdio.h>
 
void func(void) {
  char c_str[3] = "abc";
  printf("%s\n", c_str);
}

Compliant Solution

This compliant solution does not specify the bound of the character array in the array declaration. If the array bound is omitted, the compiler allocates sufficient storage to store the entire string literal, including the terminating null character.

#include <stdio.h>
 
void func(void) {
  char c_str[] = "abc";
  printf("%s\n", c_str);
}

Noncompliant Code Example

This code example is noncompliant because the wide character sequence cur_msg will not be null-terminated when passed to wcslen(). This will occur if lessen_memory_usage() is invoked while cur_msg_size still has its initial value of 1024.

#include <stdlib.h>
#include <wchar.h>
 
wchar_t

Null-terminated byte strings (NTBS) must contain a null termination character at or before the address of the last element of the array before they can be safely passed as arguments to standard string handling functions such as strcpy() or strlen(). This is because these functions, as well as other string handling functions defined by C99, depend on the existence of a null termination character to determine the length of a string. Similarly, NTBS must be null-terminated before iterating on a character array where the termination condition of the loop depends on the existence of a null termination character within the memory allocated for the string, as in the following example:

size_t i;
char ntbs[16];
/* ... */
for (i = 0; i < sizeof(ntbs); ++i) {
  if (ntbs[i] == '\0') break;
  /* ... */
}

Failure to properly terminate null-terminated byte strings can result in buffer overflows and other undefined behavior.

...

Non-Compliant Code Example (realloc())

One method to decrease memory usage in critical situations when all available memory has been exhausted is to use the realloc() function to half the size of message strings. The standard realloc() function has no concept of null-terminated byte strings. As a result, if realloc() is called to decrease the memory allocated for a null-terminated byte string, the null termination character may be truncated.

The following non-compliant code example fails to ensure that cur_msg is properly null-terminated:

char *cur_msg = NULL;
size_t cur_msg_size = 1024;

/* ... */size_t cur_msg_len = 0;

void lessen_memory_usage(void) {
  charwchar_t *temp;
  size_t temp_size;

  /* ... */

  if (cur_msg != NULL) {
    temp_size = cur_msg_size / 2 + 1;
    temp = realloc(cur_msg, temp_size * sizeof(wchar_t));
    /* temp &and cur_msg may no longer be null-terminated */
    if (temp == NULL) {
      /* Handle error condition */
    }

    cur_msg = temp;
    cur_msg_size = temp_size;
    }
}

/* ... */

Because realloc() does not guarantee that the string is properly null-terminated, any subsequent operation on cur_msg that assumes a null-termination character may result in undefined behavior.

cur_msg_len = wcslen(cur_msg); 
  }
}

Compliant Solution

...

In this compliant solution, the lessen_memory_usage() function ensures that the resulting string is always properly null-terminated. cur_msg will always be null-terminated when passed to wcslen():

Code Block
bgColor #ccccff lang c
char#include <stdlib.h> #include <wchar.h>   wchar_t *cur_msg = NULL; size_t cur_msg_size = 1024; /* ... */size_t cur_msg_len = 0; void lessen_memory_usage(void) { charwchar_t *temp; size_t temp_size; /* ... */ if (cur_msg != NULL) { temp_size = cur_msg_size / 2 + 1; temp = realloc(cur_msg, temp_size * sizeof(wchar_t)); /* temp and cur_msg may no longer be null-terminated */ if (temp == NULL) { /* Handle error condition */ } cur_msg = temp; /* Properly null-terminate cur_msg */ cur_msg[temp_size - 1] = L'\0'; cur_msg_size = temp_size; cur_msg[cur_msg_size _len = wcslen(cur_msg); } }

Noncompliant Code Example (strncpy())

Although the strncpy() function takes a string as input, it does not guarantee that the resulting value is still null-terminated. In the following noncompliant code example, if no null character is contained in the first n characters of the source array, the result will not be null-terminated. Passing a non-null-terminated character sequence to strlen() is undefined behavior.

#include <string.h>
 
enum { STR_SIZE = 32 };
 
size_t func(const char *source) {
  char c_str[STR_SIZE];
  size_t ret = 0;

  if (source) {
    c_str[sizeof(c_str) - 1] = '\0';
    strncpy(c_str, source,  /* ensure string is null-terminated */sizeof(c_str));
    ret = strlen(c_str);
  }
}

 else {
    /* ...Handle null pointer */

Mitigation Strategies

Static Analysis

Violations of this rule can be detected using local flow analysis assuming an integer range analysis to track the length of the strings. (Note: I am not entirely familiar with the literature on buffer-overflow analysis, but we should check that none of them already handle this scenario.)

• Presume that all char* parameters are NT(null-terminated). We must check that they are still NT at the end of the function. Additionally, the return value must be NT. We will also check that they are NT before being passed to another function.
• Any exceptions to the NT rule (functions that accept/return open strings) are specified separately. Given that this is C, the best option might be two hardcoded handling routines in the analysis. If the function either accepts an open string (not null-terminated) or can return an open string, we can write some code to specify this. The analysis calls these handling routines to retrieve these specifications. Another option would be to utilize the preprocessor to write in-code specifications. However, this is not in the style of C programmers. Additionally, we can't add these specs to libraries that way. Given the environment, a separate specification, in C, is probably the best option.
• The integer range analysis tracks the lengths of char*s.
• We use a tuple lattice for the analysis. The lattice has 4 elements, bottom, NT (NULL terminating), O(open) and top(unknown).
• Use the specifications (or the default of NT) to set the initial lattice element for each char*.
• If we index into the string and set a character to '\0', move the string to NT. This only occurs if the index is less than the minimum size of the string. (The integer analysis must be aware of strlen and that it works properly only on NT strings.)
• Check that the parameters to all functions match the specifications. If not, cause an error.
• At the end of the function, Check that the return value and the parameters match the specification for the function. If not, cause an error.

There is a question of what to do about character arrays. One option is to assume that char\[\] is open, and using it as a char\* means that we first must make it NULL terminating. This could get annoying for developers very quickly. I think it's better to treat char\[\] as char*, that is, we assume NT and check for it. If the exception case does occur, it will have to be specified.

This analysis also impacts STR03-A. Do not inadvertently truncate a null-terminated byte string, STR07-A. Take care when calling realloc() on a null-terminated byte string, and STR31-C. Guarantee that storage for strings has sufficient space for character data and the null termination character.

Alternative Strategies

Testing

It would probably be prohibitively expensive to come up with the test cases by hand. Another option is to use a static analysis to generate the test inputs for char*. However, it would still have to generate the inputs for the other values. We would still have to specify whether the function allows open strings or can return open strings, so that the dynamic analysis knows whether to report a defect. Since we still have to write the specifications, this technique will not save developer time there.

Dynamic Analysis

It seems the analysis won't be very different from the static analysis, in which case, we should just do this statically.

Inspection

  }
  return ret;
}

Compliant Solution (Truncation)

This compliant solution is correct if the programmer's intent is to truncate the string:

#include <string.h>
 
enum { STR_SIZE = 32 };
 
size_t func(const char *source) {
  char c_str[STR_SIZE];
  size_t ret = 0;

  if (source) {
    strncpy(c_str, source, sizeof(c_str) - 1);
    c_str[sizeof(c_str) - 1] = '\0';
    ret = strlen(c_str);
  } else {
    /* Handle null pointer */
  }
  return ret;
}

Compliant Solution (Truncation, strncpy_s())

The C Standard, Annex K strncpy_s() function can also be used to copy with truncation. The strncpy_s() function copies up to n characters from the source array to a destination array. If no null character was copied from the source array, then the nth position in the destination array is set to a null character, guaranteeing that the resulting string is null-terminated.

#define __STDC_WANT_LIB_EXT1__ 1
#include <string.h>

enum { STR_SIZE = 32 };

size_t func(const char *source) {
  char c_str[STR_SIZE];
  size_t ret = 0;

  if (source) {
    errno_t err = strncpy_s(
      c_str, sizeof(c_str), source, strnlen(source, sizeof(c_str))
    );
    if (err != 0) {
      /* Handle error */
    } else {
      ret = strnlen(c_str, sizeof(c_str));
    }
  } else {
     /* Handle null pointer */
  }
  return ret;
}

Compliant Solution (Copy without Truncation)

If the programmer's intent is to copy without truncation, this compliant solution copies the data and guarantees that the resulting array is null-terminated. If the string cannot be copied, it is handled as an error condition.

#include <string.h>
 
enum { STR_SIZE = 32 };
 
size_t func(const char *source) {
  char c_str[STR_SIZE];
  size_t ret = 0;

  if (source) {
    if (strnlen(source, sizeof(c_str)) < sizeof(c_str)) {
      strcpy(c_str, source);
      ret = strlen(c_str);
    } else {
      /* Handle string-too-large */
    }
  } else {
    /* Handle null pointer */
  }
  return ret;
}

Note that this code is not bulletproof. It gracefully handles the case where source  is NULL, when it is a valid string, and when source is not null-terminated, but at least the first 32 bytes are valid. However, in cases where source is not NULL, but points to invalid memory, or any of the first 32 bytes are invalid memory, the first call to strnlen() will access this invalid memory, and the resulting behavior is undefined. Unfortunately, standard C provides no way to prevent or even detect this condition without some external knowledge about the memory source points toAn inspection would essentially grep for known problem functions and inspect the usage. Obviously, this is extremely costly, as there would be a lot of false positives, and this does not scale well. There may also be many false negatives. Say Dev A inspects a function that returns an open string. Dev A considers it ok and documents it as such, perhaps this is one of the exception cases. Dev B might be inspecting another part of the code and might not realize that Dev A allowed an open string. It might be documented, but this is not very reliable. This might lead to a false sense of confidence that since the developers hand inspected every case that the code is fine, when in fact, a miscommunication can cause a defect.

Risk Assessment

Failure to properly null-terminate null-terminated byte strings a character sequence that is passed to a library function that expects a string can result in buffer overflows and the execution of arbitrary code with the permissions of the vulnerable process or . Null-termination errors can also result in unintended information disclosure.

Automated Detection

Related Vulnerabilities

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

References

Related Guidelines

Key here (explains table format and definitions)

CERT-CWE Mapping Notes

Key here for mapping notes

CWE-119 and STR32-C

Independent( ARR30-C, ARR38-C, ARR32-C, INT30-C, INT31-C, EXP39-C, EXP33-C, FIO37-C) STR31-C = Subset( Union( ARR30-C, ARR38-C)) STR32-C = Subset( ARR38-C)

CWE-119 = Union( STR32-C, list) where list =

• Out-of-bounds reads or writes that do not involve non-null-terminated byte strings.

CWE-125 and STR32-C

Independent( ARR30-C, ARR38-C, EXP39-C, INT30-C) STR31-C = Subset( Union( ARR30-C, ARR38-C)) STR32-C = Subset( ARR38-C)

CWE-125 = Union( STR32-C, list) where list =

• Out-of-bounds reads that do not involve non-null-terminated byte strings.

CWE-123 and STR32-C

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

Intersection( CWE-123, STR32-C) =

• Buffer overflow from passing a non-null-terminated byte string to a standard C library copying function that expects null termination, and that overwrites an (unrelated) pointer

STR32-C - CWE-123 =

• Buffer overflow from passing a non-null-terminated byte string to a standard C library copying function that expects null termination, but it does not overwrite an (unrelated) pointer

CWE-123 – STR31-C =

• Arbitrary writes that do not involve standard C library copying functions, such as strcpy()

Bibliography

...

Image Added Image Added Image Added Wiki Markup\[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\] Section 7.1.1, "Definitions of terms," Section 7.20.3.4 "The realloc function," and Section 7.21, "String handling <string.h>" \[[ISO/IEC TR 24731-1-2007|AA. C References#ISO/IEC TR 24731-1-2007]\] Section 6.7.1.4, "The strncpy_s function" \[[Schwarz 05|AA. C References#Schwarz 05]\] \[[Seacord 05|AA. C References#Seacord 05]\] Chapter 2, "Strings" \[[Viega 05|AA. C References#Viega 05]\] Section 5.2.14, "Miscalculated NULL termination"