Improper string length checking

Last revision (mm/dd/yy): //

Vulnerabilities Table of Contents

Description
Improper string length checking takes place when wide or multi-byte character strings are mistaken for standard character strings.

Consequences


 * Access control: This flaw is exploited most frequently when it results in a buffer overflow condition, which leads to arbitrary code execution.
 * Availability: Even if the flaw remains unexploded, the probability that the process will crash due to the writing of data over arbitrary memory may result in a crash.

Exposure period


 * Requirements specification: A language which is not subject to this flaw may be chosen.
 * Implementation: Misuse of string functions at implementation time is the most common cause of this problem.
 * Build: Compile-time mitigation techniques may serve to complicate exploitation.

Platform


 * Language: C, C++, Assembly
 * Platform: All

Required resources

Any

Severity

High

Likelihood  of exploit

High

There are several ways in which improper string length checking may result in an exploitable condition. All of these, however, involve the introduction of buffer overflow conditions in order to reach an exploitable state.

The first of these issues takes place when the output of a wide or multi-byte character string, string-length function is used as a size for the allocation of memory. While this will result in an output of the number of characters in the string, note that the characters are most likely not a single byte, as they are with standard character strings. So, using the size returned as the size sent to new or malloc and copying the string to this newly allocated memory will result in a buffer overflow.

Another common way these strings are misused involves the mixing of standard string and wide or multi-byte string functions on a single string. Invariably, this mismatched information will result in the creation of a possibly exploitable buffer overflow condition.

Again, if a language subject to these flaws must be used, the most effective mitigation technique is to pay careful attention to the code at implementation time and ensure that these flaws do not occur.

Risk Factors
TBD

Examples
The following example would be exploitable if any of the commented incorrect malloc calls were used.


 * 1) include 
 * 2) include 
 * 3) include 

int main { wchar_t wideString[] = L"The spazzy orange tiger jumped " \ "over the tawny jaguar."; wchar_t *newString;

printf("Strlen output: %d\nWcslen output: %d\n",         strlen(wideString), wcslen(wideString));

/* Very wrong for obvious reasons // newString = (wchar_t *) malloc(strlen(wideString)); */

/* Wrong because wide characters aren't 1 byte long! //     newString = (wchar_t *) malloc(wcslen(wideString)); */

/* correct! */     newString = (wchar_t *) malloc(wcslen(wideString) *                            sizeof(wchar_t));

/* ... */ }

The output from the printf statement would be:

Strlen output: 0 Wcslen output: 53

Related Attacks

 * Attack 1
 * Attack 2

Related Vulnerabilities

 * Buffer Overflow (and related issues)

Related Controls

 * Requirements specification: A language which is not subject to this flaw may be chosen.
 * Implementation: Ensure that if wide or multi-byte strings are in use that all functions which interact with these strings are wide and multi-byte character compatible, and that the maximum character size is taken into account when memory is allocated.
 * Build: Use of canary-style overflow prevention techniques at compile time may serve to complicate exploitation but cannot mitigate it fully; nor will this technique have any effect on process stability. This is not a complete mitigation technique.

Related Technical Impacts

 * Technical Impact 1
 * Technical Impact 2