CVE-2021-0254

A buffer size validation vulnerability in the overlayd service of Juniper Networks Junos OS may allow an unauthenticated remote attacker to send specially crafted packets to the device, triggering a partial Denial of Service (DoS) condition, or leading to remote code execution (RCE). Continued receipt and processing of these packets will sustain the partial DoS. The overlayd daemon handles Overlay OAM packets, such as ping and traceroute, sent to the overlay. The service runs as root by default and listens for UDP connections on port 4789. This issue results from improper buffer size validation, which can lead to a buffer overflow. Unauthenticated attackers can send specially crafted packets to trigger this vulnerability, resulting in possible remote code execution. overlayd runs by default in MX Series, ACX Series, and QFX Series platforms. The SRX Series does not support VXLAN and is therefore not vulnerable to this issue. Other platforms are also vulnerable if a Virtual Extensible LAN (VXLAN) overlay network is configured. This issue affects Juniper Networks Junos OS: 15.1 versions prior to 15.1R7-S9; 17.3 versions prior to 17.3R3-S11; 17.4 versions prior to 17.4R2-S13, 17.4R3-S4; 18.1 versions prior to 18.1R3-S12; 18.2 versions prior to 18.2R2-S8, 18.2R3-S7; 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R1-S8, 18.4R2-S7, 18.4R3-S7; 19.1 versions prior to 19.1R2-S2, 19.1R3-S4; 19.2 versions prior to 19.2R1-S6, 19.2R3-S2; 19.3 versions prior to 19.3R3-S1; 19.4 versions prior to 19.4R2-S4, 19.4R3-S1; 20.1 versions prior to 20.1R2-S1, 20.1R3; 20.2 versions prior to 20.2R2, 20.2R2-S1, 20.2R3; 20.3 versions prior to 20.3R1-S1.

Weakness

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

Affected Software

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.

Related Attack Patterns

• https://cwe.mitre.org/data/definitions/100.html
• https://cwe.mitre.org/data/definitions/47.html

References

• https://kb.juniper.net/JSA11147
• https://kb.juniper.net/JSA11147