SV.TAINTED.ALLOC_SIZE

Unvalidated input used in memory allocation

Whenever input is accepted from the user or the outside environment, it should be validated for type, length, format, and range before it is used. Until properly validated, the data is said to be tainted. The SV.TAINTED family of checkers looks for the use of tainted data in code.

The SV.TAINTED.ALLOC_SIZE checker flags code that uses tainted data in determining the size of a memory allocation.

Vulnerability and risk

When input to code isn't validated properly, an attacker can craft the input in a form that isn't expected by the application. The receipt of unintended input can result in altered control flow, arbitrary resource control, and arbitrary code execution. With this sort of opportunity, an attacker could

  • provide unexpected values and cause a program crash
  • cause excessive resource consumption
  • read confidential data
  • use malicious input to modify data or alter control flow
  • execute arbitrary commands

Allocating memory using integers supplied by the user can lead to excessive resource consumption. If the user passes an extremely large integer, the application will allocate an extremely large quantity of memory. This will result in the application consuming the system's memory and possibly bringing the system to a halt and triggering a denial-of-service (DoS) attack.

Mitigation and prevention

To avoid tainted input errors:

  • understand all the potential areas in which untrusted inputs could enter your software: parameters or arguments, cookies, input read from the network, environment variables, reverse DNS lookups, query results, filenames, databases, and any external systems
  • use a whitelist or 'known good' policy for inputs, rather than relying only on a blacklist or 'known bad' strategy
  • make sure all relevant properties of the input are validated, including length, type of input, ranges, missing or extra inputs, syntax, and consistency
  • if there are security checks on the client side of an applications, make sure they're duplicated on the server side
  • if the application combines inputs from multiple sources, perform the validation after the sources have been combined

Vulnerable code example

Copy 
  char *buffer = NULL;
  
  void allocateBuffer()
  {
      unsigned size;
      scanf("%u", &size);
      buffer = malloc(size);
  }

Klocwork produces an issue report at line 7 indicating that an unvalidated integer value 'size' is received through a call to 'scanf' at line 6 and can be used to alter memory allocation size through a call to 'malloc' at line 7. In this case, the SV.TAINTED.ALLOC_SIZE checker finds code that uses potentially tainted data in determining the size of a memory allocation.

Fixed code example

Copy 
  #define MAX_BUFFER_SIZE 512
  char *buffer = NULL;
  
  void allocateBuffer()
  {
      unsigned size;
      scanf("%u", &size);
      // validate input before using it in a memory allocation
      if(size <= MAX_BUFFER_SIZE)
     {
         buffer = malloc(size);
     }
 }

The Klocwork checker no longer produces an issue report because the integer value 'size' is validated before being used in a memory allocation at line 11.

Related checkers

External guidance