1. Home
  2. CWE Database
  3. CWE-170
Base · Medium

CWE-170: Improper Null Termination

The product does not terminate or incorrectly terminates a string or array with a null character or equivalent terminator.

CWE-170 · Base Level ·6 CVEs ·5 Mitigations

Description

The product does not terminate or incorrectly terminates a string or array with a null character or equivalent terminator.

Null termination errors frequently occur in two different ways. An off-by-one error could cause a null to be written out of bounds, leading to an overflow. Or, a program could use a strncpy() function call incorrectly, which prevents a null terminator from being added at all. Other scenarios are possible.

Potential Impact

Confidentiality, Integrity, Availability

Read Memory, Execute Unauthorized Code or Commands

Confidentiality, Integrity, Availability

DoS: Crash, Exit, or Restart, Read Memory, DoS: Resource Consumption (CPU), DoS: Resource Consumption (Memory)

Integrity, Availability

Modify Memory, DoS: Crash, Exit, or Restart

Integrity, Confidentiality, Availability, Access Control, Other

Alter Execution Logic, Execute Unauthorized Code or Commands

Demonstrative Examples

The following code reads from cfgfile and copies the input into inputbuf using strcpy(). The code mistakenly assumes that inputbuf will always contain a NULL terminator.
Bad
#define MAXLEN 1024...char *pathbuf[MAXLEN];...read(cfgfile,inputbuf,MAXLEN); //does not null terminatestrcpy(pathbuf,inputbuf); //requires null terminated input...
The code above will behave correctly if the data read from cfgfile is null terminated on disk as expected. But if an attacker is able to modify this input so that it does not contain the expected NULL character, the call to strcpy() will continue copying from memory until it encounters an arbitrary NULL character. This will likely overflow the destination buffer and, if the attacker can control the contents of memory immediately following inputbuf, can leave the application susceptible to a buffer overflow attack.
In the following code, readlink() expands the name of a symbolic link stored in pathname and puts the absolute path into buf. The length of the resulting value is then calculated using strlen().
Bad
char buf[MAXPATH];...readlink(pathname, buf, MAXPATH);int length = strlen(buf);...
The code above will not always behave correctly as readlink() does not append a NULL byte to buf. Readlink() will stop copying characters once the maximum size of buf has been reached to avoid overflowing the buffer, this will leave the value buf not NULL terminated. In this situation, strlen() will continue traversing memory until it encounters an arbitrary NULL character further on down the stack, resulting in a length value that is much larger than the size of string. Readlink() does return the number of bytes copied, but when this return value is the same as stated buf size (in this case MAXPATH), it is impossible to know whether the pathname is precisely that many bytes long, or whether readlink() has truncated the name to avoid overrunning the buffer. In testing, vulnerabilities like this one might not be caught because the unused contents of buf and the memory immediately following it may be NULL, thereby causing strlen() to appear as if it is behaving correctly.
While the following example is not exploitable, it provides a good example of how nulls can be omitted or misplaced, even when "safe" functions are used:
Bad
#include <stdio.h>#include <string.h>
                     int main() {
                        
                           char longString[] = "String signifying nothing";char shortString[16];
                           strncpy(shortString, longString, 16);printf("The last character in shortString is: %c (%1$x)\n", shortString[15]);return (0);
                     }
The above code gives the following output: "The last character in shortString is: n (6e)". So, the shortString array does not end in a NULL character, even though the "safe" string function strncpy() was used. The reason is that strncpy() does not impliciitly add a NULL character at the end of the string when the source is equal in length or longer than the provided size.

Mitigations & Prevention

Requirements

Use a language that is not susceptible to these issues. However, be careful of null byte interaction errors (CWE-626) with lower-level constructs that may be written in a language that is susceptible.

Implementation

Ensure that all string functions used are understood fully as to how they append null characters. Also, be wary of off-by-one errors when appending nulls to the end of strings.

Implementation

If performance constraints permit, special code can be added that validates null-termination of string buffers, this is a rather naive and error-prone solution.

Implementation

Switch to bounded string manipulation functions. Inspect buffer lengths involved in the buffer overrun trace reported with the defect.

Implementation

Add code that fills buffers with nulls (however, the length of buffers still needs to be inspected, to ensure that the non null-terminated string is not written at the physical end of the buffer).

Detection Methods

  • Automated Static Analysis High — Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then sea

Real-World CVE Examples

CVE IDDescription
CVE-2000-0312Attacker does not null-terminate argv[] when invoking another program.
CVE-2003-0777Interrupted step causes resultant lack of null termination.
CVE-2004-1072Fault causes resultant lack of null termination, leading to buffer expansion.
CVE-2001-1389Multiple vulnerabilities related to improper null termination.
CVE-2003-0143Product does not null terminate a message buffer after snprintf-like call, leading to overflow.
CVE-2009-2523Chain: product does not handle when an input string is not NULL terminated (CWE-170), leading to buffer over-read (CWE-125) or heap-based buffer overflow (CWE-122).

CWE-707: Improper Neutralization

The product does not ensure or incorrectly ensures that structured messages or data are well-formed and that certain sec...

CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')

The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than ...

CWE-126: Buffer Over-read

The product reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locatio...

CWE-147: Improper Neutralization of Input Terminators

The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special ele...

CWE-464: Addition of Data Structure Sentinel

The accidental addition of a data-structure sentinel can cause serious programming logic problems.

CWE-463: Deletion of Data Structure Sentinel

The accidental deletion of a data-structure sentinel can cause serious programming logic problems.

CWE-20: Improper Input Validation

The product receives input or data, but it does not validate or incorrectly validates that the input has the ...

Taxonomy Mappings

  • PLOVER: — Improper Null Termination
  • 7 Pernicious Kingdoms: — String Termination Error
  • CLASP: — Miscalculated null termination
  • OWASP Top Ten 2004: A9 — Denial of Service
  • CERT C Secure Coding: POS30-C — Use the readlink() function properly
  • CERT C Secure Coding: STR03-C — Do not inadvertently truncate a null-terminated byte string
  • CERT C Secure Coding: STR32-C — Do not pass a non-null-terminated character sequence to a library function that expects a string
  • Software Fault Patterns: SFP11 — Improper Null Termination

Frequently Asked Questions

What is CWE-170?

CWE-170 (Improper Null Termination) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. The product does not terminate or incorrectly terminates a string or array with a null character or equivalent terminator.

How can CWE-170 be exploited?

Attackers can exploit CWE-170 (Improper Null Termination) to read memory, execute unauthorized code or commands. This weakness is typically introduced during the Implementation phase of software development.

How do I prevent CWE-170?

Key mitigations include: Use a language that is not susceptible to these issues. However, be careful of null byte interaction errors (CWE-626) with lower-level constructs that may be written in a language that is susceptible.

What is the severity of CWE-170?

CWE-170 is classified as a Base-level weakness (Medium abstraction). It has been observed in 6 real-world CVEs.