Incorrect Calculation
Weakness ID: 682 (Weakness Class)Status: Draft
+ Description

Description Summary

The software performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.

Extended Description

When software performs a security-critical calculation incorrectly, it might lead to incorrect resource allocations, incorrect privilege assignments, or failed comparisons among other things. Many of the direct results of an incorrect calculation can lead to even larger problems such as failed protection mechanisms or even arbitrary code execution.

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Availability

If the incorrect calculation causes the program to move into an unexpected state, it may lead to a crash or impairment of service.

Integrity
Availability

If the incorrect calculation is used in the context of resource allocation, it could lead to an out-of-bounds operation (CWE-119) leading to a crash or even arbitrary code execution. Alternatively, it may result in an integer overflow (CWE-190) and / or a resource consumption problem (CWE-400).

Access Control

In the context of privilege or permissions assignment, an incorrect calculation can provide an attacker with access to sensitive resources.

Other

If the incorrect calculation leads to an insufficient comparison (CWE-697), it may compromise a protection mechanism such as a validation routine and allow an attacker to bypass the security-critical code.

+ Likelihood of Exploit

High

+ Demonstrative Examples

Example 1

The following image processing code allocates a table for images.

(Bad Code)
Example Language:
img_t table_ptr; /*struct containing img data, 10kB each*/
int num_imgs;
...
num_imgs = get_num_imgs();
table_ptr = (img_t*)malloc(sizeof(img_t)*num_imgs);
...

This code intends to allocate a table of size num_imgs, however as num_imgs grows large, the calculation determining the size of the list will eventually overflow (CWE-190). This will result in a very small list to be allocated instead. If the subsequent code operates on the list as if it were num_imgs long, it may result in many types of out-of-bounds problems (CWE-119).

Example 2

This code attempts to calculate a football team's average number of yards gained per touchdown.

(Bad Code)
Example Language: Java 
...
int touchdowns = team.getTouchdowns();
int yardsGained = team.getTotalYardage();
System.out.println(team.getName() + " averages " + yardsGained / touchdowns + "yards gained for every touchdown scored");
...
The code does not consider the event that the team they are querying has not scored a touchdown, but has gained yardage. In that case, we should expect an ArithmeticException to be thrown by the JVM. This could lead to a loss of availability if our error handling code is not set up correctly.

Example 3

This example, taken from CWE-462, attempts to calculate the position of the second byte of a pointer.

(Bad Code)
Example Language:
int *p = x;
char * second_char = (char *)(p + 1);

In this example, second_char is intended to point to the second byte of p. But, adding 1 to p actually adds sizeof(int) to p, giving a result that is incorrect (3 bytes off on 32-bit platforms). If the resulting memory address is read, this could potentially be an information leak. If it is a write, it could be a security-critical write to unauthorized memory-- whether or not it is a buffer overflow. Note that the above code may also be wrong in other ways, particularly in a little endian environment.

+ Potential Mitigations

Phase: Implementation

Understand your programming language's underlying representation and how it interacts with numeric calculation. Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, "not-a-number" calculations, and how your language handles numbers that are too large or too small for its underlying representation.

Phase: Implementation

Strategy: Input Validation

Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range.

Phase: Implementation

Use the appropriate type for the desired action. For example, in C/C++, only use unsigned types for values that could never be negative, such as height, width, or other numbers related to quantity.

Phase: Architecture and Design

Strategies: Language Selection; Libraries or Frameworks

Use languages, libraries, or frameworks that make it easier to handle numbers without unexpected consequences.

Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++).

Phase: Testing

Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible.

Phase: Testing

Use dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory189Numeric Errors
Development Concepts (primary)699
ChildOfCategoryCategory738CERT C Secure Coding Section 04 - Integers (INT)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory739CERT C Secure Coding Section 05 - Floating Point (FLP)
Weaknesses Addressed by the CERT C Secure Coding Standard734
ChildOfCategoryCategory7522009 Top 25 - Risky Resource Management
Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750
CanPrecedeWeakness BaseWeakness Base170Improper Null Termination
Research Concepts1000
ParentOfWeakness BaseWeakness Base128Wrap-around Error
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base131Incorrect Calculation of Buffer Size
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base135Incorrect Calculation of Multi-Byte String Length
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base190Integer Overflow or Wraparound
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base191Integer Underflow (Wrap or Wraparound)
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfCategoryCategory192Integer Coercion Error
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base193Off-by-one Error
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base369Divide By Zero
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant467Use of sizeof() on a Pointer Type
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base468Incorrect Pointer Scaling
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base469Use of Pointer Subtraction to Determine Size
Research Concepts (primary)1000
MemberOfViewView1000Research Concepts
Research Concepts (primary)1000
CanFollowWeakness BaseWeakness Base681Incorrect Conversion between Numeric Types
Research Concepts1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT C Secure CodingFLP32-CPrevent or detect domain and range errors in math functions
CERT C Secure CodingFLP33-CConvert integers to floating point for floating point operations
CERT C Secure CodingINT07-CUse only explicitly signed or unsigned char type for numeric values
CERT C Secure CodingINT13-CUse bitwise operators only on unsigned operands
+ Related Attack Patterns
CAPEC-IDAttack Pattern Name
(CAPEC Version: 1.4)
124Attack through Shared Data
128Integer Attacks
129Pointer Attack
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
Internal CWE Team
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential Mitigations, Time of Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships
2008-10-14CWE Content TeamMITREInternal
updated Type
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy Mappings
2009-01-12CWE Content TeamMITREInternal
updated Applicable Platforms, Common Consequences, Demonstrative Examples, Description, Likelihood of Exploit, Potential Mitigations, Relationships
2009-03-10CWE Content TeamMITREInternal
updated Potential Mitigations
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative Examples
2009-07-27CWE Content TeamMITREInternal
updated Demonstrative Examples, Related Attack Patterns
2009-10-29CWE Content TeamMITREInternal
updated Demonstrative Examples, Relationships