CVE Vulnerabilities

CVE-2024-23805

Incorrect Calculation of Buffer Size

Published: Feb 14, 2024 | Modified: Feb 14, 2024
CVSS 3.x
N/A
Source:
NVD
CVSS 2.x
RedHat/V2
RedHat/V3
Ubuntu

Undisclosed requests can cause the Traffic Management Microkernel (TMM) to terminate. For the Application Visibility and Reporting module, this may occur when the HTTP Analytics profile with URLs enabled under Collected Entities is configured on a virtual server and the DB variables avr.IncludeServerInURI or avr.CollectOnlyHostnameFromURI are enabled. For BIG-IP Advanced WAF and ASM, this may occur when either a DoS or Bot Defense profile is configured on a virtual server and the DB variables avr.IncludeServerInURI or avr.CollectOnlyHostnameFromURI are enabled.

Note: The DB variables avr.IncludeServerInURI and avr.CollectOnlyHostnameFromURI are not enabled by default. For more information about the HTTP Analytics profile and the Collect URLs setting, refer to K30875743: Create a new Analytics profile and attach it to your virtual servers https://my.f5.com/manage/s/article/K30875743 .

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated

Weakness

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

Potential Mitigations

  • Understand the programming language’s underlying representation and how it interacts with numeric calculation (CWE-681). Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, “not-a-number” calculations, and how the language handles numbers that are too large or too small for its underlying representation. [REF-7]
  • Also be careful to account for 32-bit, 64-bit, and other potential differences that may affect the numeric representation.
  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • Use libraries or frameworks that make it easier to handle numbers without unexpected consequences, or buffer allocation routines that automatically track buffer size.
  • Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++). [REF-106]
  • Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking.
  • D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.
  • Run or compile the software using features or extensions that randomly arrange the positions of a program’s executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.
  • Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as “rebasing” (for Windows) and “prelinking” (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking.
  • For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].
  • Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment.
  • For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].
  • Run the code in a “jail” or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
  • OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
  • This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
  • Be careful to avoid CWE-243 and other weaknesses related to jails.

References