Difference between revisions of "Integer overflow"

From OWASP
Jump to: navigation, search
(Related problems)
Line 1: Line 1:
 
{{Template:Vulnerability}}
 
{{Template:Vulnerability}}
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
 +
{{Template:Vulnerability}}
 +
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
==Overview==
+
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
  
An integer overflow condition exists when an integer, which has not been properly sanity checked is used in the determination of an offset or size for memory allocation, copying, concatenation, or similarly. If the integer in question is incremented past the maximum possible value, it may wrap to become a very small, or negative number, therefore providing a very incorrect value.
+
[[ASDR Table of Contents]]
 +
__TOC__
  
==Consequences ==
 
  
* Availability: Integer overflows generally lead to undefined behavior and therefore crashes. In the case of overflows involving loop index variables, the likelihood of infinite loops is also high.
+
==Description==
  
* Integrity: If the value in question is important to data (as opposed to flow), simple data corruption has occurred. Also, if the integer overflow has resulted in a buffer overflow condition, data corruption will most likely take place.
+
An integer overflow condition exists when an integer, which has not been properly sanity checked is used in the determination of an offset or size for memory allocation, copying, concatenation, or similarly. If the integer in question is incremented past the maximum possible value, it may wrap to become a very small, or negative number, therefore providing a very incorrect value.
  
* Access control (instruction processing): Integer overflows 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.
+
'''Consequences'''
  
==Exposure period ==
+
* Availability: Integer overflows generally lead to undefined behavior and therefore crashes. In the case of overflows involving loop index variables, the likelihood of infinite loops is also high.
 +
* Integrity: If the value in question is important to data (as opposed to flow), simple data corruption has occurred. Also, if the integer overflow has resulted in a buffer overflow condition, data corruption will most likely take place.
 +
* Access control (instruction processing): Integer overflows 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.
+
'''Exposure period'''
  
* Design: Mitigating technologies such as safe string libraries and container abstractions could be introduced. (This will only prevent the transition from integer overflow to buffer overflow, and only in some cases.)
+
* Requirements specification: The choice could be made to use a language that is not susceptible to these issues.
 +
* Design: Mitigating technologies such as safe string libraries and container abstractions could be introduced. (This will only prevent the transition from integer overflow to buffer overflow, and only in some cases.)
 +
* Implementation: Many logic errors can lead to this condition. It can be exacerbated by lack of or misuse of mitigating technologies.
  
* Implementation: Many logic errors can lead to this condition. It can be exacerbated by lack of or misuse of mitigating technologies.
+
'''Platform'''
  
==Platform ==
+
* Languages: C, C++, Fortran, Assembly
 +
* Operating platforms: All
  
* Languages: C, C++, Fortran, Assembly
+
'''Required resources'''
 
+
* Operating platforms: All
+
 
+
==Required resources ==
+
  
 
Any
 
Any
  
==Severity ==
+
'''Severity'''
  
 
High
 
High
  
==Likelihood of exploit ==
+
'''Likelihood of exploit'''
  
 
Medium
 
Medium
  
==Avoidance and mitigation ==
+
Integer overflows are for the most part only problematic in that they lead to issues of availability. Common instances of this can be found when primitives subject to overflow are used as a loop index variable.
  
* Pre-design: Use a language or compiler that performs automatic bounds checking.
+
In some situations, however, it is possible that an integer overflow may lead to an exploitable buffer overflow condition. In these circumstances, it may be possible for the attacker to control the size of the buffer as well as the execution of the program.  
  
* Design: Use of sanity checks and assertions at the object level. Ensure that all protocols are strictly defined, such that all out of bounds behavior can be identified simply.
+
Recently, a number of integer overflow-based, buffer-overflow conditions have surfaced in prominent software packages. Due to this fact, the relatively difficult to exploit condition is now more well known and therefore more likely to be attacked. The best strategy for mitigation includes: a multi-level strategy including the strict definition of proper behavior (to restrict scale, and therefore prevent integer overflows long before they occur); frequent sanity checks; preferably at the object level; and standard buffer overflow mitigation techniques.
  
* Pre-design through Build: Canary style bounds checking, library changes which ensure the validity of chunk data, and other such fixes are possible but should not be relied upon.
 
  
==Discussion ==
+
==Risk Factors==
  
Integer overflows are for the most part only problematic in that they lead to issues of availability. Common instances of this can be found when primitives subject to overflow are used as a loop index variable.
+
TBD
  
In some situations, however, it is possible that an integer overflow may lead to an exploitable buffer overflow condition. In these circumstances, it may be possible for the attacker to control the size of the buffer as well as the execution of the program.
+
==Examples==
 
+
Recently, a number of integer overflow-based, buffer-overflow conditions have surfaced in prominent software packages. Due to this fact, the relatively difficult to exploit condition is now more well known and therefore more likely to be attacked. The best strategy for mitigation includes: a multi-level strategy including the strict definition of proper behavior (to restrict scale, and therefore prevent integer overflows long before they occur); frequent sanity checks; preferably at the object level; and standard buffer overflow mitigation techniques.
+
  
==Examples ==
 
  
 
Integer overflows can be complicated and difficult to detect. The following example is an attempt to show how an integer overflow may lead to undefined looping behavior:
 
Integer overflows can be complicated and difficult to detect. The following example is an attempt to show how an integer overflow may lead to undefined looping behavior:
Line 71: Line 70:
 
In the above case, it is entirely possible that bytesRec may overflow, continuously creating a lower number than MAXGET and also overwriting the first MAXGET-1 bytes of buf.  
 
In the above case, it is entirely possible that bytesRec may overflow, continuously creating a lower number than MAXGET and also overwriting the first MAXGET-1 bytes of buf.  
  
==Related problems ==
 
  
* [[Buffer Overflow]] (and related vulnerabilities): [[Integer overflow]] problems are often exploited only by creating buffer overflow conditions to take advantage of.
+
==Related [[Attacks]]==
 +
 
 +
* [[Attack 1]]
 +
* [[Attack 2]]
 +
 
 +
 
 +
==Related [[Vulnerabilities]]==
 +
 
 +
* [[Buffer Overflow]] (and related vulnerabilities): [[Integer overflow]] problems are often exploited only by creating buffer overflow conditions to take advantage of.
 +
 
 +
==Related [[Controls]]==
 +
 
 +
* Pre-design: Use a language or compiler that performs automatic bounds checking.
 +
* Design: Use of sanity checks and assertions at the object level. Ensure that all protocols are strictly defined, such that all out of bounds behavior can be identified simply.
 +
* Pre-design through Build: Canary style bounds checking, library changes which ensure the validity of chunk data, and other such fixes are possible but should not be relied upon.
 +
 
 +
 
 +
==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:Vulnerability]]
 
[[Category:Range and Type Error Vulnerability]]
 
[[Category:Range and Type Error Vulnerability]]

Revision as of 09:53, 26 September 2008

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


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


Last revision (mm/dd/yy): 09/26/2008

Vulnerabilities Table of Contents

ASDR Table of Contents

Contents


Description

An integer overflow condition exists when an integer, which has not been properly sanity checked is used in the determination of an offset or size for memory allocation, copying, concatenation, or similarly. If the integer in question is incremented past the maximum possible value, it may wrap to become a very small, or negative number, therefore providing a very incorrect value.

Consequences

  • Availability: Integer overflows generally lead to undefined behavior and therefore crashes. In the case of overflows involving loop index variables, the likelihood of infinite loops is also high.
  • Integrity: If the value in question is important to data (as opposed to flow), simple data corruption has occurred. Also, if the integer overflow has resulted in a buffer overflow condition, data corruption will most likely take place.
  • Access control (instruction processing): Integer overflows 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: Mitigating technologies such as safe string libraries and container abstractions could be introduced. (This will only prevent the transition from integer overflow to buffer overflow, and only in some cases.)
  • 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

Medium

Integer overflows are for the most part only problematic in that they lead to issues of availability. Common instances of this can be found when primitives subject to overflow are used as a loop index variable.

In some situations, however, it is possible that an integer overflow may lead to an exploitable buffer overflow condition. In these circumstances, it may be possible for the attacker to control the size of the buffer as well as the execution of the program.

Recently, a number of integer overflow-based, buffer-overflow conditions have surfaced in prominent software packages. Due to this fact, the relatively difficult to exploit condition is now more well known and therefore more likely to be attacked. The best strategy for mitigation includes: a multi-level strategy including the strict definition of proper behavior (to restrict scale, and therefore prevent integer overflows long before they occur); frequent sanity checks; preferably at the object level; and standard buffer overflow mitigation techniques.


Risk Factors

TBD

Examples

Integer overflows can be complicated and difficult to detect. The following example is an attempt to show how an integer overflow may lead to undefined looping behavior:

short int bytesRec = 0;
char buf[SOMEBIGNUM];

while(bytesRec < MAXGET) {
  bytesRec += getFromInput(buf+bytesRec);
}

In the above case, it is entirely possible that bytesRec may overflow, continuously creating a lower number than MAXGET and also overwriting the first MAXGET-1 bytes of buf.


Related Attacks


Related Vulnerabilities

  • Buffer Overflow (and related vulnerabilities): Integer overflow problems are often exploited only by creating buffer overflow conditions to take advantage of.

Related Controls

  • Pre-design: Use a language or compiler that performs automatic bounds checking.
  • Design: Use of sanity checks and assertions at the object level. Ensure that all protocols are strictly defined, such that all out of bounds behavior can be identified simply.
  • Pre-design through Build: Canary style bounds checking, library changes which ensure the validity of chunk data, and other such fixes are possible but should not be relied upon.


Related Technical Impacts


References

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