Difference between revisions of "Improper string length checking"

Jump to: navigation, search
Line 2: Line 2:
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
[[ASDR Table of Contents]]
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
[[ASDR Table of Contents]]
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]

Revision as of 08:49, 2 November 2008

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.

ASDR Table of Contents

Last revision (mm/dd/yy): 11/2/2008


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


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


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

Required resources




Likelihood of exploit


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



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

#include <stdio.h>
#include <strings.h>
#include <wchar.h>

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) *  

  /* ... */

The output from the printf() statement would be:

Strlen() output: 0
Wcslen() output: 53

Related Attacks

Related Vulnerabilities

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