JUNOS (Juniper) Flaw Exposes Core Routers to Kernel Crash


A report has been received from Juniper at 4:25pm under bulletin PSN-2010-01-623 that a crafted malformed TCP field option in the TCP header of a packet will cause the JUNOS kernel to core (crash). In other words the kernel on the network device (gateway router) will crash and reboot if a packet containing this crafted option is received on a listening TCP port. The JUNOS firewall filter is unable to filter a TCP packet with this issue. Juniper claims this issue as exploit was identified during investigation of a vendor interoperability issue.

There is talk that backbone Internet providers have been quickly patching this issue since yesterday night.

TCP Header Option Space

“Options occupy space at the end of the TCP header. All options are included in the checksum. An option may begin on any byte boundary. The TCP header must be padded with zeros to make the header length a multiple of 32 bits.” (Source: http://www.networksorcery.com/enp/protocol/tcp.htm)

The TCP Header

The TCP Header

Source: http://www.software-engineer-training.com/wp-content/uploads/2007/12/tcp_header.png

The Kernel

At a high level, the kernel in an operating system serves as the bridge between applications and the actual data processing of the hardware the OS is running on. The kernel manages system resources and abstracts resources that applications must access.

Basic Kernel Representation

Basic Kernel Representation

Affected Devices

It is basically all of them save the more recent version. If you’ve installed a device with a JUNOS release version released later then 1/28/09, this issue is already corrected. Apparently the original issue and its correction did not conceive of this problem as a security vulnerability, and thus the criticality of applying the patch was not initially understood until this week.

  • JUNOS 10.x (Removed from the bulletin today, 01/07/09, so assumed to not be affected)
  • JUNOS 9.x
  • JUNOS 7.x
  • JUNOS 8.x

Please note the versions below were removed from the bulletin today, 01/07/09. This is likely because, as Matt pointed out below, these are end of life versions of the OS (meaning likely still vulnerable if you happen to be running them, but out of scope for Juniper because from their standpoint these should already have been upgraded).

  • JUNOS 6.x
  • JUNOS 5.x
  • JUNOS 3.x
  • JUNOS 4.x

Juniper’s Advice

Juniper references best common practice (BCP) 38, a methodology for reducing the amount of bad packets being forwarded by network devices (basically prohibiting packets where the originator can’t effectively be identified), as a possible mitigating control.

However there is no completely effective workaround available other then upgrading the OS.


Juniper responded to the Register as follows: “that the bulletin was one of seven security advisories the company issued under a policy designed to prevent members of the public at large from getting details of the vulnerabilities.”

“Because of Juniper’s ‘Entitled Disclosure Policy,’ only our customers and partners are allowed access to the details of the Security Advisory,”
– Juniper spokeswoman

Interesting approach, and probably would be better received if vulnerabilities only affected those entitled. Unfortunately the networks that run high end Juniper equipment serve a great many end users, and thus in this case the general public would probably like some informed background. At the point the media is contacting you, it is safe to say the “cat is out of the bag”. And this is the response from a company that is a strong player in the information security appliance space?

The flip side is that the Juniper response to this issue from a technical perspective has appeared to be at first glance fairly comprehensive, a PR opportunity if managed correctly.

And yes, this is the same firm that feels this way when it is they who are discussing the vulnerability of someone else’s product: “Juniper believes that Jack’s research (on ATM vulnerabilities) is important to be presented in a public forum in order to advance the state of security,”.

We agree with the second Juniper: more education, especially after the problem has been corrected, is better.


More information will be posted as it becomes available. This was a serious issue which appears to have been averted through a coordinated response. Essentially, given the core equipment (big Telco routers) running “Big Iron” type Juniper network devices, portions of the Internet could have gone black with a successful implementation of this exploit. Routers at this level are not patched like your local Windows OS, it takes something important to justify an outage. As previously noted, even though the code problem itself was identified last year, it appears that the problem was not identified as a mechanism for creating a remote exploit until now, raising the criticality of patching the issue severely.

Filed Under: featuredRemote Exploit

Tags: , , , ,

Comments (20)

Trackback URL | Comments RSS Feed

  1. John D says:

    “Because of Juniper’s ‘Entitled Disclosure Policy,’ only our customers and partners are allowed access to the details of the Security Advisory,” the spokeswoman wrote.

    “when a specifically crafted TCP option is received on a listening TCP port”

    funny :)

    Proof-of-Concept (PoC): http://ptresearch.blogspot.com/2010/01/juniper-junos-remote-kernel-crash-flaw.html

  2. matt says:

    just a couple of thoughts…

    1. Disclaimer: I work for Juniper.

    2. The first of the Junos 10.x releases, 10.0R1.8 was released in November, 2009 and shouldn’t be on your list.

    3. A lot of the versions you listed as susceptible to this issue have been End of Life for very a long time.

    In case anyone is curious, here’s the link to our End of Engineering / End of Life list for Junos produts.


  3. Prefect says:

    Hi Juniper Matt:

    First off, thank you for commenting. I noticed that the advisory has been updated to remove 10.x, so we’ll make that update.

    Any further color you can provide on Juniper’s efforts surrounding this? It certainly seems like a full court press to get this resolved for the big ISP’s.

    Also what are your thoughts on the initial response, captured above?

  4. [...] jest na awaryjne zakończenie pracy w wyniku odebrania specjalnie spreparowanych segmentów TCP. Błąd ten obecny jest w oprogramowaniu w wersjach od 3 do 10. Co najgorsze, nie ma żadnego sposobu na [...]

  5. [...] have noted some interesting responses since our post yesterday detailing the information in Juniper bulletin PSN-2010-01-623 and our thoughts on its somewhat [...]

  6. [...] Praetorian Prefect | JUNOS (Juniper) Flaw Exposes Core Routers to Kernel Crash [...]

  7. [...] su službeno postali dostupni. Nezavisni “Praetorian Prefect” blog, međutim, nudi informacije o ranjivoj verziji. Prema blogu, router pokretač JUNOS 9.x, 8.x ili 7.x verzije prije 28 siječnja [...]

  8. [...] Thursday Juniper released advisory PSN-2010-01-623 urging Network administrator running JUNOS versions older then one year to upgrade. The advisory [...]

  9. [...] at the Praetorian Prefect blog, there is a detailed description of the vulnerability. Categories: Security Tags: gateways, juniper Comments (0) [...]

  10. Вася says:

    ссука пиздец

  11. [...] information about the exploit can be found here and [...]

  12. [...] January 6th, we wrote about a JUNOS flaw that caused a kernel crash in Juniper routers and demonstrated the effect in action in a video. At [...]

  13. [...] be reacting,” says Daniel Kennedy, a partner with Praetorian Security Group, which has been studying the vulnerability and says it heard many ISPs were already applying the patches last [...]

  14. [...] information about the exploit can be found here and here. 14 January 2010 | Category: Uncategorized | One [...]

  15. [...] HTC Developer Center, Kernel NewbiesVia: PhandroidImage: Praetorian Perfect Amazon.com [...]