« | Home | »

Protecting your juniper router from PSN-2010-01-623 using Firewall filters

By Andree Toonk | January 10, 2010

Last Thursday Juniper released advisory PSN-2010-01-623 urging Network administrator running JUNOS versions older then one year to upgrade. The advisory states that by sending ‘malformed’ tcp options will cause JunOS to crash. The advisory does not mention which tcp options will cause this behavior.

So last Friday and Saturday I spend a few hours to trying to generate TCP packets with different kind of options set, trying to see if I could find out the exact options needed. However before I found the magic combination, Jermey Gaddis posted a blog post describing which options need to be set. He also published an exploit.

I tried running this exploit, but for some reason the perl code does not run on my Mac book. After slightly rewriting some of his perl code I managed to get it working and was ready to give it a try on one of our lab routers, a M10 running JunOS 7.x.

I was able to crash the router with only sending one packets, also see the video.

Of course most routers have firewall/acl filters to only allow traffic to the RE from trusted sources. According to the advisory and some resources online firewall filters don’t help in this case. However in my lab testing applying a firewall did seem to help.
To test this I configured my lab router with a firewall blocking all ssh traffic from all sources. I tried the exploit again and nothing happened. So it seems that at least in some cases a firewall filter does help. This might be different on a Olive box, as it doesn’t have hardware filtering in PFE’s. I assume that’s why filtering does work on a ‘real’ box, as it’s probably filtered out by the PFE’s before it reached the kernel.

Although firewall filters do seem to protect you against this issue. It’s still fairly easy to spoof IP addresses and by pass the firewall. As router Ip addresses are easy to find (traceroute) it will also be easy to guess the IP address of a BGP peer. Using that spoofed address will allow an attacker to crash your router. So upgrading to a more recent release is the only real solution.

Topics: work | 3 Comments »

3 Responses to “Protecting your juniper router from PSN-2010-01-623 using Firewall filters”

  1. Prefect Says:
    January 11th, 2010 at 4:44 am

    Nice video, this topic needs to continue to be advanced (actually would like to see some analysis of the Juniper response now that the news that the exploit is in the wild and patch out is over).

    On our end, we repeated the assertion from Juniper in the bulletin (citing Juniper) that such filtering would not be totally effective (our primary purpose being to publish our confirmation that this was an exploitable problem, and the header value not hard to find quickly so people could consider this in their risk evaluation on patching quickly). To that end, the second link to our blog in the post as a resource needing refuting is probably not appropriate 4 days after the fact.

    We continue to think and advise that reliance on such defenses (while most should be in place regardless) is not a substitute for quick analysis and patching of this problem.

  2. JeDraco Says:
    January 11th, 2010 at 5:47 am

    JunOS firewall can’t identify specific malicious packets, or spoofed ones. What’s bothersome is the security bulletin from Juniper seemed to imply firewall could not help at all.

    If your routers utilize protections such as TTL security and uRPF to prevent IP spoofing, and only accept TCP packets addressed to RE, from proper sources, then the firewall filter could be 98% effective if you have analyzed your situation carefully.

    Some network operators who already utilize these mitigation strategies fully, may have been mislead into thinking the issue effected them more seriously than it does.

    Some juniper customers may have created unnecessary service-effecting outages for their clients, to perform an emergency upgrade on reliance of the Juniper bulletin implying firewall was not a usable workaround in any case.

    That could have been delayed until a proper maintenance window, or until proper notice could be delivered.

    In other words, Juniper should have been more upfront and disclosed more information regarding WHY firewall cannot be used as an effective workaround.

  3. Andree Says:
    January 13th, 2010 at 8:39 am

    It seems that routers running 7.4 or earlier are not affected.
    Tests with 7.4, 7.2R4.2 and 5.0.0r8.0 did not result in crashes.