Difference between revisions of "Unsigned to signed conversion error"

From OWASP
Jump to: navigation, search
(Description)
 
(4 intermediate revisions by one user not shown)
Line 2: Line 2:
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
  
==Overview==
+
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
 +
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 +
 +
==Description==
 
An unsigned-to-signed conversion error takes place when a large unsigned primitive is used as an signed value - usually as a size variable.   
 
An unsigned-to-signed conversion error takes place when a large unsigned primitive is used as an signed 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 underwrite, data integrity may be affected.
 +
* Access control (instruction processing): Improper unsigned-to-signed conversions often create buffer underwrite conditions 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 underwrite, data integrity may be affected.
+
'''Exposure period'''
  
* Access control (instruction processing): Improper unsigned-to-signed conversions, often create buffer underwrite conditions 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 of 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 of 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'''
  
 
Low to Medium
 
Low to Medium
  
==Avoidance and mitigation ==
+
Although less frequent an issue than signed-to-unsigned casting, unsigned-to-signed casting can be the perfect precursor to dangerous buffer underwrite conditions that allow attackers to move down the stack where they otherwise might not have access in a normal buffer overflow condition.
  
* Requirements specification: The choice could be made to use a language that is not susceptible to these issues.
+
Buffer underwrites occur frequently when large unsigned values are cast to signed values, and then used as indexes into a buffer or for pointer arithmetic.
  
* Design: Ensure that interacting functions retain the same types and that only safe type casts must occur. If possible, use intelligent marshalling routines to translate between objects.
+
==Risk Factors==
  
* Implementation: Use out-of-data band channels for transmitting error messages if unsigned size values must be transmitted. Check all errors.
+
TBD
  
* Build: Pay attention to compiler warnings which may alert you to improper type casting.
 
  
==Discussion ==
+
==Examples==
 
+
Although less frequent an issue than signed-to-unsigned casting, unsigned-to-signed casting can be the perfect precursor to dangerous buffer underwrite conditions that allow attackers to move down the stack where they otherwise might not have access in a normal buffer overflow condition.
+
 
+
Buffer underwrites occur frequently when large unsigned values are cast to signed values, and then used as indexes into a buffer or for pointer arithmetic.
+
 
+
==Examples ==
+
  
 
While not exploitable, the following program is an excellent example of how implicit casts, while not changing the value stored, significantly changes its use:
 
While not exploitable, the following program is an excellent example of how implicit casts, while not changing the value stored, significantly changes its use:
Line 82: Line 73:
 
Note how the hex value remains unchanged.
 
Note how the hex value remains unchanged.
  
==Related problems ==
+
==Related [[Attacks]]==
 +
 
 +
* [[Attack 1]]
 +
* [[Attack 2]]
 +
 
 +
 
 +
==Related [[Vulnerabilities]]==
 +
 
 +
* [[Buffer underwrite]]
 +
 
 +
 
 +
 
 +
==Related [[Controls]]==
 +
 
 +
* Requirements specification: The choice could be made to use a language that is not susceptible to these issues.
 +
* Design: Ensure that interacting functions retain the same types and that only safe type casts must occur. If possible, use intelligent marshalling routines to translate between objects.
 +
* Implementation: Use out-of-data band channels for transmitting error messages if unsigned size values must be transmitted. Check all errors.
 +
* Build: Pay attention to compiler warnings which may alert you to improper type casting.
 +
 
 +
==Related [[Technical Impacts]]==
 +
 
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
 +
 
 +
 
 +
==References==
 +
 
 +
TBD
 +
[[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]]
  
* [[Buffer underwrite]]
+
__NOTOC__
  
  
 +
[[Category:OWASP ASDR Project]]
 
[[Category:Vulnerability]]
 
[[Category:Vulnerability]]
 
[[Category:Range and Type Error Vulnerability]]
 
[[Category:Range and Type Error Vulnerability]]

Latest revision as of 08:43, 1 March 2009

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



Last revision (mm/dd/yy): 03/1/2009

Vulnerabilities Table of Contents

Description

An unsigned-to-signed conversion error takes place when a large unsigned primitive is used as an signed 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 underwrite, data integrity may be affected.
  • Access control (instruction processing): Improper unsigned-to-signed conversions often create buffer underwrite conditions 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 of or misuse of mitigating technologies.

Platform

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

Required resources

Any

Severity

High

Likelihood of exploit

Low to Medium

Although less frequent an issue than signed-to-unsigned casting, unsigned-to-signed casting can be the perfect precursor to dangerous buffer underwrite conditions that allow attackers to move down the stack where they otherwise might not have access in a normal buffer overflow condition.

Buffer underwrites occur frequently when large unsigned values are cast to signed values, and then used as indexes into a buffer or for pointer arithmetic.

Risk Factors

TBD


Examples

While not exploitable, the following program is an excellent example of how implicit casts, while not changing the value stored, significantly changes its use:

#include <stdio.h>
		
int main() {   
  int value;    
  value = (int)(~((int)0) ^ (1 << (sizeof(int)*8)));    

  printf("Max unsigned int: %u %1$x\nNow signed: %1$d %1$x\n",
         value);    
  return (0);
}

The above code produces the following output:

Max unsigned int: 4294967295 ffffffff
Now signed: -1 ffffffff

Note how the hex value remains unchanged.

Related Attacks


Related Vulnerabilities


Related Controls

  • Requirements specification: The choice could be made to use a language that is not susceptible to these issues.
  • Design: Ensure that interacting functions retain the same types and that only safe type casts must occur. If possible, use intelligent marshalling routines to translate between objects.
  • Implementation: Use out-of-data band channels for transmitting error messages if unsigned size values must be transmitted. Check all errors.
  • Build: Pay attention to compiler warnings which may alert you to improper type casting.

Related Technical Impacts


References

TBD