Difference between revisions of "Signed to unsigned conversion error"

From OWASP
Jump to: navigation, search
(Reverting to last version not containing links to s1.shard.jp)
 
(13 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 +
{{Template:Vulnerability}}
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
  
==Overview==
+
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
 +
[[ASDR_TOC_Vulnerabilities|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.
 
A signed-to-unsigned conversion error takes place when a signed primitive is used as an unsigned value, usually as a size variable.
  
==Consequences ==
+
'''Consequences'''
  
* Availability: Incorrect sign conversions generally lead to undefined behavior, and therefore crashes.
+
* 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.
  
* Integrity: If a poor cast lead to a buffer overflow or similar condition, data integrity may be affected.
+
'''Exposure period'''
  
* 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.
+
* 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.
  
==Exposure period ==
+
'''Platform'''
  
* Requirements specification: The choice could be made to use a language that is not susceptible to these issues.
+
* Languages: C, C++, Fortran, Assembly
 +
* Operating platforms: All
  
* Design: Accessor functions may be designed to mitigate some of these logical issues.
+
'''Required resources'''
 
+
* 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
 
Any
  
==Severity ==
+
'''Severity'''
  
 
High
 
High
  
==Likelihood   of exploit ==
+
'''Likelihood of exploit'''
  
 
Medium
 
Medium
  
==Avoidance and mitigation ==
+
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.  
 
+
* 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.
+
 
+
==Discussion ==
+
 
+
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.  
 
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.
 
Also, if the variables in question are used as indexes into a buffer, it may result in a buffer underflow condition.
 
==Examples ==
 
  
 
In the following example, it is possible to request that memcpy move a much larger segment of memory than assumed:
 
In the following example, it is possible to request that memcpy move a much larger segment of memory than assumed:
Line 76: Line 63:
 
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.
 
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.
  
==Related problems ==
 
  
* [[Buffer overflow]] (and related conditions)
+
==Risk Factors==
  
* [[Buffer underwrite]]
+
TBD
  
 +
==Examples==
 +
TBD
  
[[Category:Vulnerability]]
+
==Related [[Attacks]]==
  
[[Category:Range and Type Errors]]
+
* [[Attack 1]]
 +
* [[Attack 2]]
  
 +
 +
==Related [[Vulnerabilities]]==
 +
 +
* [[Buffer Overflow]] (and related conditions)
 +
* [[Buffer underwrite]]
 +
 +
==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]]==
 +
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
 +
 +
 +
==References==
 +
Note: A reference to related [http://cwe.mitre.org/ CWE] or [http://capec.mitre.org/ CAPEC] article should be added when exists. Eg:
 +
 +
* [http://cwe.mitre.org/data/definitions/79.html CWE 79].
 +
* http://www.link1.com
 +
* [http://www.link2.com Title for the link2]
 +
 +
[[Category:FIXME|add links
 +
 +
In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>
 +
 +
Availability Vulnerability
 +
 +
Authorization Vulnerability
 +
 +
Authentication Vulnerability
 +
 +
Concurrency Vulnerability
 +
 +
Configuration Vulnerability
 +
 +
Cryptographic Vulnerability
 +
 +
Encoding Vulnerability
 +
 +
Error Handling Vulnerability
 +
 +
Input Validation Vulnerability
 +
 +
Logging and Auditing Vulnerability
 +
 +
Session Management Vulnerability]]
 +
 +
__NOTOC__
 +
 +
 +
[[Category:OWASP ASDR Project]]
 +
[[Category:Vulnerability]]
 +
[[Category:Range and Type Error Vulnerability]]
 
[[Category:OWASP_CLASP_Project]]
 
[[Category:OWASP_CLASP_Project]]
 +
[[Category:Code Snippet]]
 +
[[Category:C]]

Latest revision as of 07:49, 3 June 2009

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



Last revision (mm/dd/yy): 06/3/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: