Slashdot Mirror


VPN Flaw Allows Denial of Service

An anonymous reader writes "Finnish researchers at the University of Oulu have found a vulnerability in ISAKMP (Internet Security Association and Key Management Protocol) -- the technology used in IPsec virtual private network and firewall products from a range of networking companies, including Cisco and Juniper Networks. Cisco said the security flaw could cause devices to reset over and over, which could cause a temporary denial-of-service attack. It did not mention the possibility of the device being taken over by an intruder, while Juniper said it has been aware of the problem since June, so software issued on or after July 28 provide fixes for the flaw."

17 of 64 comments (clear)

  1. This seems like a protocol issue by Anonymous Coward · · Score: 3, Insightful

    and not an implementation failure. So how exactly are individual vendors patching it without changing the protocol? Or are they making changes in the protocol that would be "invisible" to the outside world?

    1. Re:This seems like a protocol issue by JimBowen · · Score: 2, Insightful

      I expect it is just a hack which fixes the security hole, while causing the implementation to no longer comply with the standard for the protocol.
      Though one would hope this doesn't cause problems in itself.. :/

    2. Re:This seems like a protocol issue by Homology · · Score: 4, Informative
      and not an implementation failure. So how exactly are individual vendors patching it without changing the protocol? Or are they making changes in the protocol that would be "invisible" to the outside world?

      The advisory says:

      Multiple ISAKMP implementations behave in anomalous way when they receive and handle ISAKMP Phase 1 packets with invalid and/or abnormal contents. By applying the OUSPG PROTOS ISAKMP Test Suite to a variety of products, several vulnerabilities can be revealed that can have varying effects.

      The OpenBSD developers fixed this early 2004 :

      > I just tested our isakmpd(8) implementation against the PROTOS
      > test suite. No problems were detected. We performed an audit
      > of isakmpd's IKE parsing code back in early 2004 and made several
      > fixes (OpenBSD 3.4 timeframe).
      >
      > I also ran the PROTOS suite against tcpdump -vvv and saw no
      > problems.

      Please also note that both these programs are priv sep'd, so that
      in the event a bug is found, the impact will be much reduced.
  2. Original publication by Anonymous Coward · · Score: 3, Informative

    http://www.ee.oulu.fi/research/ouspg/protos/testin g/c09/isakmp/index.html

    "ABSTRACT

    The Internet Security Association and Key Management Protocol (ISAKMP), is designed to establish, negotiate, modify and delete Security Associations. ISAKMP provides a consistent framework for transferring key and authentication data which is independent of the key generation technique, encryption algorithm and authentication mechanism. Internet Key Exchange (IKE), a derivate of ISAKMP, is a key protocol in the Internet Security Architecture (IPsec). A subset of IKE Phase 1 negotiation was chosen as the subject protocol for vulnerability assessment through syntax testing and test-suite creation. A survey of the related standards was made. Test-material was prepared and tests were carried out against a sample set of existing implementations. Results were gathered and reported. Some of the implementations available for evaluation failed to perform in a robust manner under the test. Some failures had information security implications, and should be considered as vulnerabilities. Therefore, this robustness test-material should be adopted for evaluation and development of ISAKMP/IKE products."

  3. There is not a lot of info on NISCC site by arivanov · · Score: 5, Insightful

    The blurb has nearly no meaningfull information whatsoever. The only meaningfull bit is the recommendation not to use aggressive mode.

    Well... We kind'a all know this already. The weaknesses of agressive mode were all over BUGTRAQ more then 2 years ago and if you are still using it you "Get whatever Christmas you deserve".

    --
    Baker's Law: Misery no longer loves company. Nowadays it insists on it
    http://www.sigsegv.cx/
  4. Oh Cisco... by emptycorp · · Score: 3, Funny

    Gotta love a company that keeps administrators like me with job security :)

  5. Try again. by piranha(jpl) · · Score: 4, Informative

    FTFA:

    Multiple ISAKMP implementations behave in anomalous way when they receive and handle ISAKMP Phase 1 packets with invalid and/or abnormal contents. By applying the OUSPG PROTOS ISAKMP Test Suite to a variety of products, several vulnerabilities can be revealed that can have varying effects.

    That doesn't strike me as a protocol problem.

  6. There does not seem to be any IPsec exploiting by pe1chl · · Score: 4, Interesting

    We have been running IPsec on Cisco routers for quite some time.
    We have always had an explicit allow list for isakmp packets only for the known peers, and a deny with logging for all other sources.
    Over the years, there have been only very few logged packets. No need to tell you how many NETBIOS and other wellknown exploitable service packets have been counted (we don't even log these).

    It does not look like IPsec is a popular attack vector. Same for PPTP, by the way.

  7. Thanks Jupiner! by jacoplane · · Score: 5, Funny

    "Juniper said it has been aware of the problem since June, so software issued on or after July 28 provide fixes for the flaw."

    Gee, thanks for letting the rest of the world know too!

  8. Summary by hal9000(jr) · · Score: 3, Insightful

    Feed a server carefully crafted, malformed packets and it may behave in unpredictable ways. We show that several IPSec implementations of IKE V1 don't behave properly.

    Not news kids, just development as usual.

    Oh, and I like the bit about "possibly executing code." That, I believe, is FUD. Prove that you can execute code.

  9. Looks like implementation by mikeborella · · Score: 3, Informative

    Some lab ran a protocol tester against some ISAKMP implementations and found a few issues. No reason to panic as long as the vendors fix it. It is pretty common to fix these sorts of bugs it complicated protocols like ISAKMP.

    --
    Mike Borella http://www.borella.net/mike
  10. Well, I knew something was up... by Penguin+Follower · · Score: 2, Interesting

    ... since my router started randomly reloading a few days ago. I wonder if Cisco will release a patched version of the IOS that's free, cause I cannot afford the "cisco tax". I bought that router while I was a student ( and in the cisco academy program ) to practice with the IOS. I had been using the router for my cable connection since then. But, if I cannot get a free update I'll be going to get one of those inexpensive linksys or netgear routers for my home connection now.

    Yay, I now have a $500 cisco paper weight.

    1. Re:Well, I knew something was up... by forged · · Score: 3, Informative
      No free software upgrade ?

      From the Cisco security advisory:

      Summary

      Multiple Cisco products contain vulnerabilities in the processing of IPSec IKE (Internet Key Exchange) messages. These vulnerabilities were identified by the University of Oulu Secure Programming Group (OUSPG) "PROTOS" Test Suite for IPSec and can be repeatedly exploited to produce a denial of service.

      Cisco has made free software available to address this vulnerability for affected customers. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. (emphasis mine)

      Then later in the same document, there's a whole section about Obtaining Fixed Software including a subsection for Customers without Service Contracts (emphasis mine) which I assume is your case.

  11. Well that's pretty dumb. by Some+Random+Username · · Score: 2, Insightful

    OpenVPN has had several VERY STUPID security problems discovered recently. Why not just keep using ipsec, but don't buy a shitty broken implimentation from cisco? http://www.openbsd.org/

  12. CheckPoint's Reply by xaosflux · · Score: 2, Informative

    From CheckPoint Solutions:
    Solution ID: #sk31316
    Product: VPN-1/FireWall-1
    Version: NG AI, NGX
    Last Modified: 14-Nov-2005

    Symptoms
    On Monday, November 14th, NISCC has issued a warning about a possible denial of service condition for IKEv1. No known exploit exists.
    (NISCC Vulnerability Advisory 273756)

    Cause
    This issue was identified using the PROTOS ISAKMP Test Suite for IKEv1 which was published through NISCC.

    The issue is due to a problem with the implementation of the IKE protocol.
    The issue might cause a crash of the IKE daemon (vpnd) during the processing of IKE packet 5.

    An attacker needs to perform a full IKE negotiation with the attacked VPN gateway in order to cause the denial of service condition; no single packet attack is possible.
    No further exploit is possible.
    There is no possibility of code execution relating to this issue.
    Given the nature of the issue, crafting an exploit is extremely difficult.

    Solution
    Install the latest HFA (HotFix Accumulator)

  13. And, how do you get that update? by gordonb · · Score: 2, Interesting

    Juniper does not issue patches to JunOS, including ex-Netscreen ScreenOS. In order to get the latest firmware, you must have a support contract with Juniper at a cost of hundreds to thousands per year per device. If you have let your contract lapse, you need to pay the fee for every year since your last subscription up to the present year. They will not simply sell you the firmware, even if you have a legitimate licencse and registered device. If you use an EOL device, such as the common Netscreen 5XP, you are SOL.

  14. Okey, soooo.... by Kalzus · · Score: 2, Informative

    They tested a bunch of implementations and a bunch of them failed out over 5000 different tests. How is this a problem with the protocol itself as opposed to how a bunch of vendors decided to implement it?

    Might've been better phrased if it read as a vulnerability with "a number of popular implementations of IKEv1" as opposed to a vulnerability with the protocol.

    --
    "The Devil does not know a lot because He's the Devil, He knows a lot because he's old." -- unknown