CVE-2021-0243

Improper Handling of Unexpected Data in the firewall policer of Juniper Networks Junos OS on EX4300 switches allows matching traffic to exceed set policer limits, possibly leading to a limited Denial of Service (DoS) condition. When the firewall policer discard action fails on a Layer 2 port, it will allow traffic to pass even though it exceeds set policer limits. Traffic will not get discarded, and will be forwarded even though a policer discard action is configured. When the issue occurs, traffic is not discarded as desired, which can be observed by comparing the Input bytes with the Output bytes using the following command: user@junos> monitor interface traffic Interface Link Input bytes (bps) Output bytes (bps) ge-0/0/0 Up 37425422 (82616) 37425354 (82616) «« egress ge-0/0/1 Up 37425898 (82616) 37425354 (82616) «« ingress The expected output, with input and output counters differing, is shown below: Interface Link Input bytes (bps) Output bytes (bps) ge-0/0/0 Up 342420570 (54600) 342422760 (54600) «« egress ge-0/0/1 Up 517672120 (84000) 342420570 (54600) «« ingress This issue only affects IPv4 policing. IPv6 traffic and firewall policing actions are not affected by this issue. This issue affects Juniper Networks Junos OS on the EX4300: All versions prior to 17.3R3-S10; 17.4 versions prior to 17.4R3-S3; 18.1 versions prior to 18.1R3-S11; 18.2 versions prior to 18.2R3-S6; 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R3-S6; 19.1 versions prior to 19.1R3-S3; 19.2 versions prior to 19.2R3-S1; 19.3 versions prior to 19.3R3-S1; 19.4 versions prior to 19.4R3; 20.1 versions prior to 20.1R2; 20.2 versions prior to 20.2R2.

Weakness

The product does not handle or incorrectly handles when a particular element is not the expected type, e.g. it expects a digit (0-9) but is provided with a letter (A-Z).

Affected Software

Potential Mitigations

• Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
• When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”
• Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code’s environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Related Attack Patterns

• https://cwe.mitre.org/data/definitions/48.html

References

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