Difference between revisions of "Signed to unsigned conversion error"

From OWASP
Jump to: navigation, search
(Examples)
Line 69: Line 69:
  
 
==Examples==
 
==Examples==
 
+
TBD
===Short example name===
+
: A short example description, small picture, or sample code with [http://www.site.com links]
+
 
+
===Short example name===
+
: A short example description, small picture, or sample code with [http://www.site.com links]
+
 
+
  
 
==Related [[Attacks]]==
 
==Related [[Attacks]]==

Revision as of 15:54, 28 February 2009

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



Last revision (mm/dd/yy): 02/28/2009

Vulnerabilities Table of Contents

Description

A signed-to-unsigned conversion error takes place when a signed primitive is used as an unsigned value, usually as a size variable.

Consequences

  • Availability: Incorrect sign conversions generally lead to undefined behavior, and therefore crashes.
  • Integrity: If a poor cast leads to a buffer overflow or similar condition, data integrity may be affected.
  • Access control (instruction processing): Improper signed-to-unsigned conversions without proper checking can sometimes trigger buffer overflows which can be used to execute arbitrary code. This is usually outside the scope of a program's implicit security policy.

Exposure period

  • Requirements specification: The choice could be made to use a language that is not susceptible to these issues.
  • Design: Accessor functions may be designed to mitigate some of these logical issues.
  • Implementation: Many logic errors can lead to this condition. It can be exacerbated by lack, or misuse, of mitigating technologies.

Platform

  • Languages: C, C++, Fortran, Assembly
  • Operating platforms: All

Required resources

Any

Severity

High

Likelihood of exploit

Medium

Often, functions will return negative values to indicate a failure state. In the case of functions which return values which are meant to be used as sizes, negative return values can have unexpected results. If these values are passed to the standard memory copy or allocation functions, they will implicitly cast the negative error, indicating value to a large unsigned value.

In the case of allocation, this may not be an issue; however, in the case of memory and string copy functions, this can lead to a buffer overflow condition which may be exploitable.

Also, if the variables in question are used as indexes into a buffer, it may result in a buffer underflow condition.

In the following example, it is possible to request that memcpy move a much larger segment of memory than assumed:

int returnChunkSize(void *) {
  /* if chunk info is valid, return the size of usable memory, 
   * else, return -1 to indicate an error
   */
   .... 
}

int main() {
  ... 
  memcpy(destBuf, srcBuf, (returnChunkSize(destBuf)-1));
  ...
}

If returnChunkSize() happens to encounter an error, and returns -1, memcpy will assume that the value is unsigned and therefore interpret it as MAXINT-1, therefore copying far more memory than is likely available in the destination buffer.


Risk Factors

TBD

Examples

TBD

Related Attacks


Related Vulnerabilities

Related Controls

  • Requirements specification: Choose a language which is not subject to these casting flaws.
  • Design: Design object accessor functions to implicitly check values for valid sizes. Ensure that all functions which will be used as a size are checked previous to use as a size. If the language permits, throw exceptions rather than using in-band errors.
  • Implementation: Error check the return values of all functions. Be aware of implicit casts made, and use unsigned variables for sizes if at all possible.


Related Technical Impacts


References

Note: A reference to related CWE or CAPEC article should be added when exists. Eg: