Unsigned to Signed Conversion Error

Draft Variant
Structure: Simple
Description

This vulnerability occurs when a program takes an unsigned integer and converts it directly to a signed integer. If the original unsigned value is too large to fit within the signed type's positive range, the conversion results in an unexpected negative number, corrupting the data.

Extended Description

While less common than signed-to-unsigned errors, this conversion flaw is a critical enabler for buffer underwrite attacks. When a large unsigned value (like a size or index) becomes a large negative number after conversion, using it for array indexing or pointer arithmetic can shift memory access far below the intended buffer's start. This "underwrite" or "buffer underflow" grants attackers write access to sensitive stack memory, such as function return addresses or saved registers, which they typically cannot reach in a standard overflow. This vulnerability is particularly dangerous because it subverts common security assumptions. Developers often guard against overly large positive values but may not anticipate an index turning negative. The resulting out-of-bounds write can lead to arbitrary code execution, often with fewer detection hurdles than a classic buffer overflow, making it a subtle but powerful exploit precursor.

Common Consequences 3
Scope: Availability

Impact: DoS: Crash, Exit, or Restart

Incorrect sign conversions generally lead to undefined behavior, and therefore crashes.

Scope: Integrity

Impact: Modify Memory

If a poor cast lead to a buffer overflow or similar condition, data integrity may be affected.

Scope: IntegrityConfidentialityAvailabilityAccess Control

Impact: Execute Unauthorized Code or CommandsBypass Protection Mechanism

Improper signed-to-unsigned conversions without proper checking 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.

Potential Mitigations 3
Phase: Requirements
Choose a language which is not subject to these casting flaws.
Phase: Architecture and Design
Design object accessor functions to implicitly check values for valid sizes. Ensure that all functions which will be used as a size are checked previous to use as a size. If the language permits, throw exceptions rather than using in-band errors.
Phase: Implementation
Error check the return values of all functions. Be aware of implicit casts made, and use unsigned variables for sizes if at all possible.
References 2
The Art of Software Security Assessment
Mark Dowd, John McDonald, and Justin Schuh
Addison Wesley
2006
ID: REF-62
The CLASP Application Security Process
Secure Software, Inc.
2005
ID: REF-18
Likelihood of Exploit

Medium

Applicable Platforms
Languages:
C : UndeterminedC++ : Undetermined
Modes of Introduction
Implementation
Taxonomy Mapping
  • CLASP
  • Software Fault Patterns