• CWE-196: Unsigned to Signed Conversion Error

Das Produkt verwendet einen unsigned primitiven Datentyp und führt einen Cast zu einem signed primitiven Datentyp durch, was zu einem unerwarteten Wert führen kann, falls der Wert des unsigned primitiven Datentyps nicht mit einem signed primitiven Datentyp dargestellt werden kann.

CWE-196: Unsigned to Signed Conversion Error

CWE ID: 196
Name: Unsigned to Signed Conversion Error

Beschreibung

Das Produkt verwendet einen unsigned primitiven Datentyp und führt einen Cast zu einem signed primitiven Datentyp durch, was zu einem unerwarteten Wert führen kann, falls der Wert des unsigned primitiven Datentyps nicht mit einem signed primitiven Datentyp dargestellt werden kann.

Erweiterte Beschreibung

Obwohl die Konvertierung von signed zu unsigned weniger häufig ein Problem darstellt, kann die Konvertierung von unsigned zu signed der perfekte Vorläufer für gefährliche buffer underrun Bedingungen sein. Diese ermöglichen es Angreifern, sich im Stack zu bewegen, wo sie unter normalen buffer overflow Bedingungen keinen Zugriff hätten. Buffer underruns treten häufig auf, wenn große unsigned Werte in signed Werte umgewandelt und anschließend als Indizes in einen Puffer oder für pointer arithmetic verwendet werden.

Risikominderungsmaßnahmen

Maßnahme (Requirements)

Effektivität: Unknown
Beschreibung: Choosing a language not susceptible to these casting flaws is a worthwhile consideration for enhanced security. Rust stands out as a strong candidate. Its ownership system and strict type checking effectively prevent the implicit conversions and unchecked arithmetic that often lead to buffer underruns and similar vulnerabilities found in languages like C and C++. Rust’s compiler enforces memory safety at compile time, significantly reducing the risk of these kinds of errors during runtime. While other languages offer some protections, Rust’s approach is particularly robust in this regard.

Maßnahme (Architecture and Design)

Effektivität: Unknown
Beschreibung: To enhance robustness and prevent size-related errors, we should design object accessor functions to implicitly validate values before they are utilized as sizes. A key principle is to ensure that every function intended to be used as a size undergoes a preliminary check. Where the language supports it, leveraging exceptions rather than relying on in-band error handling is the preferred approach for signaling invalid size conditions.

Specifically, this means implementing checks within the accessor functions themselves. For example, if a function returns a size_t value, it should verify that the value is non-negative and within reasonable bounds dictated by the context. If the value is invalid, a std::invalid_argument exception (or equivalent in the specific language) should be thrown. This proactive validation minimizes the potential for downstream errors and facilitates more reliable code execution. The goal is to shift the responsibility for size validation to the accessor functions, thereby reducing the burden on the calling code and improving overall system stability. This approach aligns with principles of defensive programming and contributes to a more secure and maintainable codebase.

Maßnahme (Implementation)

Effektivität: Unknown
Beschreibung: It is imperative to rigorously error-check the return values of all functions. Particular attention should be paid to any implicit casts that may occur, as these can mask underlying issues and lead to unexpected behavior. To ensure accuracy and prevent potential overflows, the use of unsigned variables for representing sizes is strongly recommended whenever feasible. This practice helps to avoid negative values and provides a more appropriate representation for quantities that inherently cannot be negative. Consistent error checking and the use of unsigned variables contribute significantly to the reliability and integrity of the system.