Weakness · High
CWE-839: Numeric Range Comparison Without Minimum Check
What it is
The product checks a value to ensure that it is less than or equal to a maximum, but it does not also verify that the value is greater than or equal to the minimum.
- Severity (our rating)
- High
- Likelihood of exploit
- Not rated by MITRE
- Introduced during
- Implementation
- Exploited in the wild
- No CVE in CISA's catalog
In more detail
Some products use signed integers or floats even when their values are only expected to be positive or 0. An input validation check might assume that the value is positive, and only check for the maximum value. If the value is negative, but the code assumes that the value is positive, this can produce an error. The error may have security consequences if the negative value is used for memory allocation, array access, buffer access, etc. Ultimately, the error could lead to a buffer overflow or other type of memory corruption. The use of a negative number in a positive-only context could have security implications for other types of resources. For example, a shopping cart might check that the user is not requesting more than 10 items, but a request for -3 items could cause the application to calculate a negative price and credit the attacker's account.
What an attacker can do
- Modify Application Data (Integrity, Confidentiality, Availability)
- Execute Unauthorized Code or Commands (Integrity, Confidentiality, Availability)
- DoS: Resource Consumption (Other) (Availability)
- Modify Memory (Confidentiality, Integrity)
- Read Memory (Confidentiality, Integrity)
How to prevent it
Implementation
- If the number to be used is always expected to be positive, change the variable type from signed to unsigned or size_t.
- If the number to be used could have a negative value based on the specification (thus requiring a signed value), but the number should only be positive to preserve code correctness, then include a check to ensure that the value is positive.
How to find it
- Automated Static Analysis. Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
H2 Security
Found it in your code?
We review where it appears, fix it with your team, and check it was not already used against you.
Talk to our teamT Academy
Stop writing it in the first place
Learn to build software and systems without weaknesses like this one, with practice on real hosts in your browser, every objective checked on the machine.
Start freeSource: MITRE Common Weakness Enumeration, CWE version 4.19.1. CWE is a trademark of The MITRE Corporation.