An uncontrolled resource consumption vulnerability in Juniper Networks Junos OS on QFX5000 Series and EX4600 Series switches allows an attacker sending large amounts of legitimate traffic destined to the device to cause Interchassis Control Protocol (ICCP) interruptions, leading to an unstable control connection between the Multi-Chassis Link Aggregation Group (MC-LAG) nodes which can in turn lead to traffic loss. Continued receipt of this amount of traffic will create a sustained Denial of Service (DoS) condition. An indication that the system could be impacted by this issue is the following log message: "DDOS_PROTOCOL_VIOLATION_SET: Warning: Host-bound traffic for protocol/exception LOCALNH:aggregate exceeded its allowed bandwidth at fpc <fpc number> for <n> times, started at <timestamp>" This issue affects Juniper Networks Junos OS on QFX5000 Series and EX4600 Series: 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-S5; 18.3 versions prior to 18.3R3-S5; 18.4 versions prior to 18.4R2-S8, 18.4R3-S7; 19.1 versions prior to 19.1R3-S5; 19.2 versions prior to 19.2R1-S6, 19.2R3-S2; 19.3 versions prior to 19.3R2-S6, 19.3R3-S2; 19.4 versions prior to 19.4R1-S4, 19.4R2-S4, 19.4R3-S2; 20.1 versions prior to 20.1R2-S2, 20.1R3; 20.2 versions prior to 20.2R2-S3, 20.2R3; 20.3 versions prior to 20.3R2; 20.4 versions prior to 20.4R1-S1, 20.4R2.
When user-defined ARP Policer is configured and applied on one or more Aggregated Ethernet (AE) interface units, a Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability between the Device Control Daemon (DCD) and firewall process (dfwd) daemons of Juniper Networks Junos OS allows an attacker to bypass the user-defined ARP Policer. In this particular case the User ARP policer is replaced with default ARP policer. To review the desired ARP Policers and actual state one can run the command "show interfaces <> extensive" and review the output. See further details below. An example output is: show interfaces extensive | match policer Policer: Input: __default_arp_policer__ <<< incorrect if user ARP Policer was applied on an AE interface and the default ARP Policer is displayed Policer: Input: jtac-arp-ae5.317-inet-arp <<< correct if user ARP Policer was applied on an AE interface For all platforms, except SRX Series: This issue affects Juniper Networks Junos OS: All versions 5.6R1 and all later versions prior to 18.4 versions prior to 18.4R2-S9, 18.4R3-S9 with the exception of 15.1 versions 15.1R7-S10 and later versions; 19.4 versions prior to 19.4R3-S3; 20.1 versions prior to 20.1R3; 20.2 versions prior to 20.2R3-S2; 20.3 version 20.3R1 and later versions; 20.4 versions prior to 20.4R3; 21.1 versions prior to 21.1R2; This issue does not affect Juniper Networks Junos OS versions prior to 5.6R1. On SRX Series this issue affects Juniper Networks Junos OS: 18.4 versions prior to 18.4R2-S9, 18.4R3-S9; 19.4 versions prior to 19.4R3-S4; 20.1 versions prior to 20.1R3; 20.2 versions prior to 20.2R3-S2; 20.3 version 20.3R1 and later versions; 20.4 versions prior to 20.4R3; 21.1 versions prior to 21.1R2. This issue does not affect 18.4 versions prior to 18.4R1 on SRX Series. This issue does not affect Junos OS Evolved.
A Race Condition (Concurrent Execution using Shared Resource with Improper Synchronization) vulnerability in the firewall process (dfwd) of Juniper Networks Junos OS allows an attacker to bypass the firewall rule sets applied to the input loopback filter on any interfaces of a device. This issue is detectable by reviewing the PFE firewall rules, as well as the firewall counters and seeing if they are incrementing or not. For example: show firewall Filter: __default_bpdu_filter__ Filter: FILTER-INET-01 Counters: Name Bytes Packets output-match-inet 0 0 <<<<<< missing firewall packet count This issue affects: Juniper Networks Junos OS 14.1X53 versions prior to 14.1X53-D53 on QFX Series; 14.1 versions 14.1R1 and later versions prior to 15.1 versions prior to 15.1R7-S6 on QFX Series, PTX Series; 15.1X53 versions prior to 15.1X53-D593 on QFX Series; 16.1 versions prior to 16.1R7-S7 on QFX Series, PTX Series; 16.2 versions prior to 16.2R2-S11, 16.2R3 on QFX Series, PTX Series; 17.1 versions prior to 17.1R2-S11, 17.1R3-S2 on QFX Series, PTX Series; 17.2 versions prior to 17.2R1-S9, 17.2R3-S3 on QFX Series, PTX Series; 17.3 versions prior to 17.3R2-S5, 17.3R3-S7 on QFX Series, PTX Series; 17.4 versions prior to 17.4R2-S9, 17.4R3 on QFX Series, PTX Series; 18.1 versions prior to 18.1R3-S9 on QFX Series, PTX Series; 18.2 versions prior to 18.2R2-S6, 18.2R3-S3 on QFX Series, PTX Series; 18.3 versions prior to 18.3R1-S7, 18.3R2-S3, 18.3R3-S1 on QFX Series, PTX Series; 18.4 versions prior to 18.4R1-S5, 18.4R2-S3, 18.4R2-S7, 18.4R3 on QFX Series, PTX Series; 19.1 versions prior to 19.1R1-S4, 19.1R2-S1, 19.1R3 on QFX Series, PTX Series; 19.2 versions prior to 19.2R1-S3, 19.2R2 on QFX Series, PTX Series.
Due to a vulnerability in DDoS protection in Juniper Networks Junos OS and Junos OS Evolved on QFX5K Series switches in a VXLAN configuration, instability might be experienced in the underlay network as a consequence of exceeding the default ddos-protection aggregate threshold. If an attacker on a client device on the overlay network sends a high volume of specific, legitimate traffic in the overlay network, due to an improperly detected DDoS violation, the leaf might not process certain L2 traffic, sent by spines in the underlay network. Continued receipt and processing of the high volume traffic will sustain the Denial of Service (DoS) condition. This issue affects: Juniper Networks Junos OS on QFX5K Series: 17.3 versions prior to 17.3R3-S11; 17.4 versions prior to 17.4R3-S5; 18.1 versions prior to 18.1R3-S13; 18.2 versions prior to 18.2R2-S8, 18.2R3-S8; 18.3 versions prior to 18.3R3-S5; 18.4 versions prior to 18.4R1-S8, 18.4R2-S6, 18.4R3-S6; 19.1 versions prior to 19.1R3-S4; 19.2 versions prior to 19.2R1-S6, 19.2R3-S2; 19.3 versions prior to 19.3R3-S2; 19.4 versions prior to 19.4R2-S4, 19.4R3-S1; 20.1 versions prior to 20.1R2; 20.2 versions prior to 20.2R2; 20.3 versions prior to 20.3R1-S2, 20.3R2. Juniper Networks Junos OS Evolved on QFX5220: All versions prior to 20.3R2-EVO.
On Juniper Networks EX4300-MP Series, EX4600 Series, EX4650 Series, QFX5K Series deployed as a Virtual Chassis with a specific Layer 2 circuit configuration, Packet Forwarding Engine manager (FXPC) process may crash and restart upon receipt of specific layer 2 frames. Continued receipt and processing of this packet will create a sustained Denial of Service (DoS) condition. This issue affects: Juniper Networks Junos OS on EX4300-MP Series, EX4600 Series, EX4650 Series, QFX5K Series 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, 17.4R3-S5; 18.2 versions prior to 18.2R3-S8; 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R2-S7, 18.4R3-S6; 19.1 versions prior to 19.1R3-S4; 19.2 versions prior to 19.2R1-S6, 19.2R3-S1; 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; 20.2 versions prior to 20.2R2, 20.2R3; 20.3 versions prior to 20.3R1-S2, 20.3R2;
A vulnerability in processing of certain DHCP packets from adjacent clients on EX Series and QFX Series switches running Juniper Networks Junos OS with DHCP local/relay server configured may lead to exhaustion of DMA memory causing a Denial of Service (DoS). Over time, exploitation of this vulnerability may cause traffic to stop being forwarded, or to crashing of the fxpc process. When Packet DMA heap utilization reaches 99%, the system will become unstable. Packet DMA heap utilization can be monitored through the following command: user@junos# request pfe execute target fpc0 timeout 30 command "show heap" ID Base Total(b) Free(b) Used(b) % Name -- ---------- ----------- ----------- ----------- --- ----------- 0 213301a8 536870488 387228840 149641648 27 Kernel 1 91800000 8388608 3735120 4653488 55 DMA 2 92000000 75497472 74452192 1045280 1 PKT DMA DESC 3 d330000 335544320 257091400 78452920 23 Bcm_sdk 4 96800000 184549376 2408 184546968 99 Packet DMA <--- 5 903fffe0 20971504 20971504 0 0 Blob An indication of the issue occurring may be observed through the following log messages: Dec 10 08:07:00.124 2020 hostname fpc0 brcm_pkt_buf_alloc:523 (buf alloc) failed allocating packet buffer Dec 10 08:07:00.126 2020 hostname fpc0 (buf alloc) failed allocating packet buffer Dec 10 08:07:00.128 2020 hostname fpc0 brcm_pkt_buf_alloc:523 (buf alloc) failed allocating packet buffer Dec 10 08:07:00.130 2020 hostnameC fpc0 (buf alloc) failed allocating packet buffer This issue affects Juniper Networks Junos OS on EX Series and QFX Series: 17.4R3 versions prior to 17.4R3-S3; 18.1R3 versions between 18.1R3-S6 and 18.1R3-S11; 18.2R3 versions prior to 18.2R3-S6; 18.3R3 versions prior to 18.3R3-S4; 18.4R2 versions prior to 18.4R2-S5; 18.4R3 versions prior to 18.4R3-S6; 19.1 versions between 19.1R2 and 19.1R3-S3; 19.2 versions prior to 19.2R3-S1; 19.3 versions prior to 19.3R2-S5, 19.3R3; 19.4 versions prior to 19.4R2-S2, 19.4R3; 20.1 versions prior to 20.1R2; 20.2 versions prior to 20.2R1-S2, 20.2R2. Junos OS versions prior to 17.4R3 are unaffected by this vulnerability.
On Juniper Networks EX and QFX5K Series platforms configured with Redundant Trunk Group (RTG), Storm Control profile applied on the RTG interface might not take affect when it reaches the threshold condition. Storm Control enables the device to monitor traffic levels and to drop broadcast, multicast, and unknown unicast packets when a specified traffic level is exceeded, thus preventing packets from proliferating and degrading the LAN. Note: this issue does not affect EX2200, EX3300, EX4200, and EX9200 Series. This issue affects Juniper Networks Junos OS on EX Series and QFX5K Series: 15.1 versions prior to 15.1R7-S7; 16.1 versions prior to 16.1R7-S8; 17.2 versions prior to 17.2R3-S4; 17.3 versions prior to 17.3R3-S8; 17.4 versions prior to 17.4R2-S11, 17.4R3-S2; 18.1 versions prior to 18.1R3-S10; 18.2 versions prior to 18.2R3-S5; 18.3 versions prior to 18.3R2-S4, 18.3R3-S2; 18.4 versions prior to 18.4R2-S5, 18.4R3-S3; 19.1 versions prior to 19.1R2-S2, 19.1R3-S2; 19.2 versions prior to 19.2R1-S5, 19.2R2-S1, 19.2R3; 19.3 versions prior to 19.3R2-S4, 19.3R3; 19.4 versions prior to 19.4R1-S3, 19.4R2-S1, 19.4R3; 20.1 versions prior to 20.1R1-S2, 20.1R2.
An improper interpretation conflict of certain data between certain software components within the Juniper Networks Junos OS devices does not allow certain traffic to pass through the device upon receipt from an ingress interface filtering certain specific types of traffic which is then being redirected to an egress interface on a different VLAN. This causes a Denial of Service (DoS) to those clients sending these particular types of traffic. Such traffic being sent by a client may appear genuine, but is non-standard in nature and should be considered as potentially malicious, and can be targeted to the device, or destined through it for the issue to occur. This issues affects IPv4 and IPv6 traffic. An indicator of compromise may be found by checking log files. You may find that traffic on the input interface has 100% of traffic flowing into the device, yet the egress interface shows 0 pps leaving the device. For example: [show interfaces "interface" statistics detail] Output between two interfaces would reveal something similar to: Ingress, first interface: -------------------- Interface Link Input packets (pps) Output packets (pps) et-0/0/0 Up 9999999999 (9999) 1 (0) -------------------- Egress, second interface: -------------------- Interface Link Input packets (pps) Output packets (pps) et-0/0/1 Up 0 (0) 9999999999 (0) -------------------- Dropped packets will not show up in DDoS monitoring/protection counters as issue is not caused by anti-DDoS protection mechanisms. This issue affects: Juniper Networks Junos OS: 17.3 versions prior to 17.3R3-S7 on NFX250, QFX5K Series, EX4600; 17.4 versions prior to 17.4R2-S11, 17.4R3-S3 on NFX250, QFX5K Series, EX4600; 18.1 versions prior to 18.1R3-S9 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4600; 18.2 versions prior to 18.2R3-S3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600; 18.3 versions prior to 18.3R3-S1 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 18.4 versions prior to 18.4R1-S5, 18.4R2-S3, 18.4R3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.1 versions prior to 19.1R1-S5, 19.1R2-S1, 19.1R3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.2 versions prior to 19.2R1-S5, 19.2R2 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.3 versions prior to 19.3R2-S3, 19.3R3 on NFX250, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series; 19.4 versions prior to 19.4R1-S2, 19.4R2 on NFX250, NFX350, QFX5K Series, EX2300 Series, EX3400 Series, EX4300 Multigigabit, EX4600 Series. This issue does not affect Junos OS releases prior to 17.2R2.
When configuring stateless firewall filters in Juniper Networks EX4600 and QFX 5000 Series devices using Virtual Extensible LAN protocol (VXLAN), the discard action will fail to discard traffic under certain conditions. Given a firewall filter configuration similar to: family ethernet-switching { filter L2-VLAN { term ALLOW { from { user-vlan-id 100; } then { accept; } } term NON-MATCH { then { discard; } } when there is only one term containing a 'user-vlan-id' match condition, and no other terms in the firewall filter except discard, the discard action for non-matching traffic will only discard traffic with the same VLAN ID specified under 'user-vlan-id'. Other traffic (e.g. VLAN ID 200) will not be discarded. This unexpected behavior can lead to unintended traffic passing through the interface where the firewall filter is applied. This issue only affects systems using VXLANs. This issue affects Juniper Networks Junos OS on QFX5K Series: 18.1 versions prior to 18.1R3-S7, except 18.1R3; 18.2 versions prior to 18.2R2-S7, 18.2R3-S1; 18.3 versions prior to 18.3R1-S5, 18.3R2-S4, 18.3R3; 18.4 versions prior to 18.4R1-S7, 18.4R2-S1, 18.4R3; 19.1 versions prior to 19.1R1-S5, 19.1R2; 19.2 versions prior to 19.2R1-S5, 19.2R2.
On Juniper Networks EX4300-MP Series, EX4600 Series and QFX5K Series deployed in a Virtual Chassis configuration, receipt of a stream of specific layer 2 frames can cause high CPU load, which could lead to traffic interruption. This issue does not occur when the device is deployed in Stand Alone configuration. The offending layer 2 frame packets can originate only from within the broadcast domain where the device is connected. This issue affects Juniper Networks Junos OS on EX4300-MP Series, EX4600 Series and QFX5K Series: 17.3 versions prior to 17.3R3-S9; 17.4 versions prior to 17.4R2-S11, 17.4R3-S2, 17.4R3-S3; 18.1 versions prior to 18.1R3-S11; 18.2 versions prior to 18.2R3-S5; 18.3 versions prior to 18.3R2-S4, 18.3R3-S3; 18.4 versions prior to 18.4R2-S5, 18.4R3-S4; 19.1 versions prior to 19.1R3-S2; 19.2 versions prior to 19.2R1-S5, 19.2R3; 19.3 versions prior to 19.3R2-S4, 19.3R3; 19.4 versions prior to 19.4R1-S3, 19.4R2-S1, 19.4R3; 20.1 versions prior to 20.1R1-S3, 20.1R2.