Product Affected

This issue can affect any product or platform utilizing an em interface for communications, including M, T, MX, SRX5400/5600/5800, EX, QFX, PTX Series, and MAG-Series CMC.
High
7.8 (AV:N/AC:L/Au:N/C:N/I:N/A:C)

Problem

Traffic between the RE and transit interfaces is carried over an internal network between the PFEs and REs. Some REs use em interfaces (usually, em0 and em1) to connect to this network. Receipt of a carefully crafted set of fragmented packets, destined to the router, can cause the em driver to become permanently blocked when trying to formulate a reply. This will cause the RE to be unable to communicate over the private network that connects the FPCs and REs eventually causing all FPCs to go offline and stay offline. Systems with redundant REs will failover, but would then be subject to the same issue. For systems without modular FPCs (for example, MX80), the FPC will reboot and clear the em0 interface output queue. However, additional crafted fragments will cause the issue to reoccur.

This issue is applicable to IPv4, IPv6, and CLNP fragmentation and reassembly scenarios. Transit traffic does not trigger this issue. Additionally, CLNP is only vulnerable if clns-routing or ESIS is explicitly configured,

This issue is specific to em interfaces. J Series and SRX Series models not listed above do not utilize the em driver, and are therefore not affected by this issue. In addition, some REs (e.g. K2RE based systems) may use an em driver for their "fxp0" interface. On such REs, reply traffic sent out the fxp0 interface may trigger the same condition on that interface. Refer to the "Supported Routing Engines by Router" link below for more information about internal Ethernet interface types for specific platforms. Customers can confirm the presence of em interfaces by typing:

% pciconf -l | grep em
em0@pci3:0:0: class="0x020000" card=0x00901059 chip=0x10d38086 rev=0x00 hdr=0x00
em1@pci4:0:0: class="0x020000" card=0x00901059 chip=0x10d38086 rev=0x00 hdr=0x00
em2@pci5:0:0: class="0x020000" card=0x00901059 chip=0x10d38086 rev=0x00 hdr=0x00

This issue was found during internal product security testing.

Juniper SIRT is not aware of any malicious exploitation of this vulnerability.

No other Juniper Networks products or platforms are affected by this issue.

This issue has been assigned CVE-2014-6380 .

Solution

The following software releases have been updated to resolve this specific issue: Junos OS 11.4R11, 12.1R9, 12.1X44-D30, 12.1X45-D20, 12.1X46-D15, 12.1X47-D10, 12.2R8, 12.2X50-D70, 12.3R6, 13.1R4, 13.1X49-D55, 13.1X50-D30, 13.2R4, 13.2X50-D20, 13.2X51-D15, 13.2X52-D15, 13.3R1, and all subsequent releases.

This issue is being tracked as PR 942437 and is visible on the Customer Support website.

KB16765 [juniper.net] - "In which releases are vulnerabilities fixed?" describes which release vulnerabilities are fixed as per our End of Engineering and End of Life support policies.

How to obtain fixed software:

Security vulnerabilities in Junos are fixed in the next available Maintenance Release of each supported Junos version. In some cases, a Maintenance Release is not planned to be available in an appropriate time-frame. For these cases, Service Releases are made available in order to be more timely. Security Advisory and Security Notices will indicate which Maintenance and Service Releases contain fixes for the issues described. Upon request to JTAC, customers will be provided download instructions for a Service Release. Although Juniper does not provide formal Release Note documentation for a Service Release, a list of "PRs fixed" can be provided on request.

Workaround

Today's network infrastructure typically will not have fragmented packets destined for the router's control or management plane. In most cases, it is safe to apply packet filters which will prevent fragmented packets from arriving on the router. Usually, fragmented packets received by a router indicate a problem with the network or a DoS attack against the router. In either case, fragmented packets should be dropped to protect the router's control and management plane.

Below is a sample firewall filter to demonstrate this recommendation for IPv4 traffic: 

[edit firewall family inet filter fragment]
user@junos# show
term first-frag {
    from {
        first-fragment;
    }
    then {
        discard;
    }
}
term next-frag {
    from {
        is-fragment;
    }
    then {
        discard;
    }
}

And for IPv6: 

 
[edit firewall family inet6 filter fragment6]
user@junos# show
term fragment-headers {
    from {
        next-header [ hop-by-hop dstopts routing fragment ah esp ];
    }
    then {
        discard;
    }
}

Caution: Some routing protocols, such as BGP and OSPF, may rely upon fragmented traffic being received by the RE. In addition, proper operation of IPv6 multicast may require that the router accept some traffic with hop-by-hop headers. As with any control plane firewall filter, perform careful testing in your environment to ensure that dropping all fragmented traffic will not have a negative impact. If necessary, add explicit exceptions for fragmented BGP and/or OSPF traffic to the sample IPv4 firewall filter above, or add limited exceptions to the IPv6 firewall filter above to allow hop-by-hop headers for multicast control traffic (such as MLD).

Note that some platforms — most notably the EX Series — do not support the ' first-fragment ' filter criterion. In these cases, simply discarding all fragments via ' is-fragment ' will be sufficient. Additionally, the EX-8200 does not support either criteria, in which case the only option is to upgrade.

For CLNP, disabling CLNS routing and ESIS, which are disabled by default, will mitigate this issue.

Severity Assessment

Information for how Juniper Networks uses CVSS can be found at KB 16446 [juniper.net] "Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories."

Related Information

Acknowledgements