CWE-131 Details

The product does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow.

Einführungsmodi

Implementation

Anwendbare Plattformen

Sprache

Class: Memory-Unsafe (Undetermined)
Name: C (Undetermined)
Name: C++ (Undetermined)

Häufige Konsequenzen

Beobachtete Beispiele

Mögliche Gegenmaßnahmen

Phases : Implementation
When allocating a buffer for the purpose of transforming, converting, or encoding an input, allocate enough memory to handle the largest possible encoding. For example, in a routine that converts "&" characters to "&" for HTML entity encoding, the output buffer needs to be at least 5 times as large as the input buffer.
Phases : Implementation
Phases : Implementation
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.
Phases : Architecture and Design
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Phases : Implementation
When processing structured incoming data containing a size field followed by raw data, identify and resolve any inconsistencies between the size field and the actual size of the data (CWE-130).
Phases : Implementation
When allocating memory that uses sentinels to mark the end of a data structure - such as NUL bytes in strings - make sure you also include the sentinel in your calculation of the total amount of memory that must be allocated.
Phases : Implementation
Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available.
Phases : Implementation
Use sizeof() on the appropriate data type to avoid CWE-467.
Phases : 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. This will simplify validation and will reduce surprises related to unexpected casting.
Phases : Architecture and Design
Phases : Operation // Build and Compilation
Phases : Operation // Build and Compilation
Phases : Operation
Phases : Implementation
Examine compiler warnings closely and eliminate problems with potential security implications, such as signed / unsigned mismatch in memory operations, or use of uninitialized variables. Even if the weakness is rarely exploitable, a single failure may lead to the compromise of the entire system.
Phases : Architecture and Design // Operation
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Phases : Architecture and Design // Operation

Erkennungsmethoden

Automated Static Analysis

Wirksamkeit : High

Automated Dynamic Analysis

This weakness can be detected using 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.
Wirksamkeit : Moderate

Automated Dynamic Analysis

Use tools that are integrated during compilation to insert runtime error-checking mechanisms related to memory safety errors, such as AddressSanitizer (ASan) for C/C++ [REF-1518].
Wirksamkeit : Moderate

Manual Analysis

Manual analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. This becomes difficult for weaknesses that must be considered for all inputs, since the attack surface can be too large.

Manual Analysis

Wirksamkeit : High

Automated Static Analysis - Binary or Bytecode

Wirksamkeit : High

Manual Static Analysis - Binary or Bytecode

Wirksamkeit : SOAR Partial

Manual Static Analysis - Source Code

Wirksamkeit : SOAR Partial

Automated Static Analysis - Source Code

Wirksamkeit : High

Architecture or Design Review

Wirksamkeit : High

Hinweise zur Schwachstellen-Zuordnung

Begründung : This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Kommentar : Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Verwandte Angriffsmuster

Hinweise

Referenzen

REF-106

SafeInt
David LeBlanc, Niels Dekker.
https://github.com/dcleblanc/SafeInt/

REF-107

Top 25 Series - Rank 18 - Incorrect Calculation of Buffer Size
Jason Lam.
https://www.sans.org/blog/top-25-series-rank-18-incorrect-calculation-of-buffer-size

REF-58

Address Space Layout Randomization in Windows Vista
Michael Howard.
https://learn.microsoft.com/en-us/archive/blogs/michael_howard/address-space-layout-randomization-in-windows-vista

REF-61

Understanding DEP as a mitigation technology part 1
Microsoft.
https://msrc.microsoft.com/blog/2009/06/understanding-dep-as-a-mitigation-technology-part-1/

REF-60

PaX
https://en.wikipedia.org/wiki/Executable_space_protection#PaX

REF-76

Least Privilege
Sean Barnum, Michael Gegick.
https://web.archive.org/web/20211209014121/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege

REF-7

Writing Secure Code
Michael Howard, David LeBlanc.
https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223

REF-44

24 Deadly Sins of Software Security
Michael Howard, David LeBlanc, John Viega.

REF-62

The Art of Software Security Assessment
Mark Dowd, John McDonald, Justin Schuh.

REF-64

Position Independent Executables (PIE)
Grant Murphy.
https://www.redhat.com/en/blog/position-independent-executables-pie

REF-1332

Prelink and address space randomization
John Richard Moser.
https://lwn.net/Articles/190139/

REF-1333

Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR
Dmitry Evtyushkin, Dmitry Ponomarev, Nael Abu-Ghazaleh.
http://www.cs.ucr.edu/~nael/pubs/micro16.pdf

REF-1334

Stack Frame Canary Validation (D3-SFCV)
D3FEND.
https://d3fend.mitre.org/technique/d3f:StackFrameCanaryValidation/

REF-1335

Segment Address Offset Randomization (D3-SAOR)
D3FEND.
https://d3fend.mitre.org/technique/d3f:SegmentAddressOffsetRandomization/

REF-1336

Process Segment Execution Prevention (D3-PSEP)
D3FEND.
https://d3fend.mitre.org/technique/d3f:ProcessSegmentExecutionPrevention/

REF-1337

Bypassing Browser Memory Protections: Setting back browser security by 10 years
Alexander Sotirov and Mark Dowd.
https://www.blackhat.com/presentations/bh-usa-08/Sotirov_Dowd/bh08-sotirov-dowd.pdf

REF-1479

State-of-the-Art Resources (SOAR) for Software Vulnerability Detection, Test, and Evaluation
Gregory Larsen, E. Kenneth Hong Fong, David A. Wheeler, Rama S. Moorthy.
https://www.ida.org/-/media/feature/publications/s/st/stateoftheart-resources-soar-for-software-vulnerability-detection-test-and-evaluation/p-5061.ashx

REF-1482

D3FEND: D3-TL Trusted Library
D3FEND.
https://d3fend.mitre.org/technique/d3f:TrustedLibrary/

REF-1518

AddressSanitizer
https://clang.llvm.org/docs/AddressSanitizer.html

Einreichung

Änderungen