COMMON WEAKNESS ENUMERATIONIncomplete

CWE-1389

Incorrect Parsing of Numbers with Different Radices

The product parses numeric input assuming base 10 (decimal) values, but it does not account for inputs that use a different base number (radix).

Abstraction

Base

Structure

Simple

Likelihood of Exploit

Medium

Understand the problem

What is the problem?

The product parses numeric input assuming base 10 (decimal) values, but it does not account for inputs that use a different base number (radix).

Extended description

Frequently, a numeric input that begins with "0" is treated as octal, or "0x" causes it to be treated as hexadecimal, e.g. by the inet_addr() function. For example, "023" (octal) is 35 decimal, or "0x31" is 49 decimal. Other bases may be used as well. If the developer assumes decimal-only inputs, the code could produce incorrect numbers when the inputs are parsed using a different base. This can result in unexpected and/or dangerous behavior. For example, a "0127.0.0.1" IP address is parsed as octal due to the leading "0", whose numeric value would be the same as 87.0.0.1 (decimal), where the developer likely expected to use 127.0.0.1. The consequences vary depending on the surrounding code in which this weakness occurs, but they can include bypassing network-based access control using unexpected IP addresses or netmasks, or causing apparently-symbolic identifiers to be processed as if they are numbers. In web applications, this can enable bypassing of SSRF restrictions.

Root cause

How and when does the problem arise?

Lifecycle phase

Implementation

Input validation used may assume decimal bases during conditional checks, when it may not always be the case.

Lifecycle phase

Implementation

The application may rely on a service that supports different numerical bases.

Risk

What does successful exploitation lead to?

Read Application Data

Affected security scopes: Confidentiality

An attacker may use an unexpected numerical base to access private application resources.
Bypass Protection MechanismAlter Execution Logic

Affected security scopes: Integrity

An attacker may use an unexpected numerical base to bypass or manipulate access control mechanisms.

Defence

How is it prevented and fixed?

Implementation

Enforcement by Conversion

Detail
If only decimal-based values are expected in the application, conditional checks should be created in a way that prevent octal or hexadecimal strings from being checked. This can be achieved by converting any numerical string to an explicit base-10 integer prior to the conditional check, to prevent octal or hex values from ever being checked against the condition.

Implementation

Input Validation

Detail
If various numerical bases do need to be supported, check for leading values indicating the non-decimal base you wish to support (such as 0x for hex) and convert the numeric strings to integers of the respective base. Reject any other alternative-base string that is not intentionally supported by the application.

Implementation

Input Validation

Detail
If regular expressions are used to validate IP addresses, ensure that they are bounded using ^ and $ to prevent base-prepended IP addresses from being matched.

Verification

How is it detected?

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.)