CVE Vulnerabilities

CVE-2023-47039

Heap-based Buffer Overflow

Published: Jan 02, 2024 | Modified: Nov 21, 2024
CVSS 3.x
7.8
HIGH
Source:
NVD
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.x
RedHat/V2
RedHat/V3
7.8 MODERATE
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Ubuntu
NEGLIGIBLE

A vulnerability was found in Perl. This security issue occurs while Perl for Windows relies on the system path environment variable to find the shell (cmd.exe). When running an executable that uses the Windows Perl interpreter, Perl attempts to find and execute cmd.exe within the operating system. However, due to path search order issues, Perl initially looks for cmd.exe in the current working directory. This flaw allows an attacker with limited privileges to placecmd.exe in locations with weak permissions, such as C:ProgramData. By doing so, arbitrary code can be executed when an administrator attempts to use this executable from these compromised locations.

Weakness

A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc().

Affected Software

Name Vendor Start Version End Version
Perl Perl * 5.32.1 (excluding)
Perl Ubuntu bionic *
Perl Ubuntu devel *
Perl Ubuntu esm-infra-legacy/trusty *
Perl Ubuntu esm-infra/bionic *
Perl Ubuntu esm-infra/xenial *
Perl Ubuntu focal *
Perl Ubuntu jammy *
Perl Ubuntu lunar *
Perl Ubuntu mantic *
Perl Ubuntu trusty *
Perl Ubuntu trusty/esm *
Perl Ubuntu upstream *
Perl Ubuntu xenial *
Perl6 Ubuntu bionic *
Perl6 Ubuntu esm-apps/bionic *
Perl6 Ubuntu esm-apps/focal *
Perl6 Ubuntu focal *
Perl6 Ubuntu trusty *
Perl6 Ubuntu upstream *
Perl6 Ubuntu xenial *
Raku Ubuntu bionic *
Raku Ubuntu devel *
Raku Ubuntu lunar *
Raku Ubuntu mantic *
Raku Ubuntu trusty *
Raku Ubuntu upstream *
Raku Ubuntu xenial *

Potential Mitigations

  • 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].

References