Page History

...

Noncompliant Code Example

This noncompliant code In this example, adapted from the Cryptography Services blog, demonstrates how signed overflow can occur even when it seems that only unsigned types are in use:a character is iterated from 0 to CHAR_MAX. However, on a platform where char is signed (such as 32-bit x86), max  is set to 0x80  while i  increments from 0x79  to {{0xffffff80} (aka -127):

#include <limits.h>

unsigned shortchar xmax = 45000, y = 50000;
unsigned int z = x * y;

On implementations where short is 16 bits wide and int is 32 bits wide, the program results in undefined behavior due to signed overflow. This is because the unsigned shorts become signed when they are automatically promoted to integer, and their mathematical product (2250000000) is greater than the largest signed 32-bit integer (2³¹ - 1, which is 2147483647).

Compliant Solution

In this compliant solution, by manually casting one of the operands to unsigned int, the multiplication will be unsigned and so will not result in undefined behavior:

unsigned short x = 45000, y = 50000;
unsigned int z = x * (unsigned int)y;

Risk Assessment

Misunderstanding integer conversion rules can lead to errors, which in turn can lead to exploitable vulnerabilities. The major risks occur when narrowing the type (which requires a specific cast or assignment), converting from unsigned to signed, or converting from negative to unsigned.

...

Recommendation

...

Severity

...

Likelihood

...

Remediation Cost

...

Priority

...

Level

...

INT02-C

...

Medium

...

Probable

...

Medium

...

P8

...

L2

CHAR_MAX + 1;
for (char i = 0; i < max; ++i) {
  printf("i=0x%08x max=0x%08x\n", i, max);
}

Compliant Solution

There are several ways to rectify this example. One way is to treat both chars as unsigned, which prevents wraparound:

#include <limits.h>

unsigned char max = CHAR_MAX + 1;
for (unsigned char i = 0; i < max; ++i) {
  printf("i=0x%08x max=0x%08x\n", i, max);
}

Noncompliant Code Example

This noncompliant code example, adapted from the Cryptography Services blog, demonstrates how signed overflow can occur even when it seems that only unsigned types are in use:

unsigned short x = 45000, y = 50000;
unsigned int z = x * y;

On implementations where short is 16 bits wide and int is 32 bits wide, the program results in undefined behavior due to signed overflow. This is because the unsigned shorts become signed when they are automatically promoted to integer, and their mathematical product (2250000000) is greater than the largest signed 32-bit integer (2³¹ - 1, which is 2147483647).

Compliant Solution

In this compliant solution, by manually casting one of the operands to unsigned int, the multiplication will be unsigned and so will not result in undefined behavior:

unsigned short x = 45000, y = 50000;
unsigned int z = x * (unsigned int)y;

Risk Assessment

Misunderstanding integer conversion rules can lead to errors, which in turn can lead to exploitable vulnerabilities. The major risks occur when narrowing the type (which requires a specific cast or assignment), converting from unsigned to signed, or converting from negative to unsigned.

Automated Detection

Automated Detection

Related Vulnerabilities

This vulnerability in Adobe Flash arises because Flash passes a signed integer to calloc(). An attacker has control over this integer and can send negative numbers. Because calloc() takes size_t, which is unsigned, the negative number is converted to a very large number, which is generally too big to allocate, and as a result, calloc() returns NULL, causing the vulnerability to exist.

...