multiple payload handling flaws in isakmpd

From: Thomas Walpuski (thomas_at_thinknerd.de)
Date: 11/02/03

  • Next message: bugzilla_at_redhat.com: "[RHSA-2003:309-01] Updated fileutils/coreutils package fix ls vulnerabilities" 
    Date: Sun, 2 Nov 2003 22:08:26 +0100
To: bugtraq@securityfocus.com

    1 Abstract

      isakmpd's, OpenBSD's IKE daemon's, payload handling, especially the
      handling of delete payloads, contains numerous more or less severe
      flaws, which allow for unauthorized deletion of IKE and IPsec SAs.

    2 Description

      2.1
      
        isakmpd does not require encryption for messages in Quick Mode,
        although RFC 2409, section 5.5 says:
        
          The information exchanged along with Quick Mode MUST be protected
          by the ISAKMP SA-- i.e. all payloads except the ISAKMP header are
          encrypted.

        This also applies to the last two (one for each, initiator and
        responder) messages of Main mode, informational exchanges, ... See
        RFC 2408, section 4.5 and RFC 2409, sections 5.1 to 5.4 and 5.7

      2.2
     
        When acting as responder in Quick Mode exchanges, isakmpd does not
        apply payload encryption as long as the initiator itself also does
        not apply payload encryption, because isakmpd relies on the
        following lines of code in message_recv() in message.c:
        
          if (flags & ISAKMP_FLAGS_ENC)
              msg->exchange->flags |= EXCHANGE_FLAG_ENCRYPT;

        Main Mode is not affected as isakmpd sets the encryption flag
        explicit in {initiator,resonder}_send_ID_AUTH in ike_main_mode.c

      2.3

        isakmpd does only require hash payloads (which contain (H)MACs
        indeed) for messages directly relating to Quick Mode exchanges.
        "Phase 2" messages containing delete payloads ("delete messages"),
        for example, do not need to include a hash payload to be accepted by
        isakmpd, albeit RFC 2409, section 5.7 requires these "delete
        messages" to include a hash payload. This also applies to notify
        messages of type status in phase 2, although RFC 2407, section 4.6.3
        prescribes their protection:

          Notification Status Messages MUST be sent under the protection of
          an ISAKMP SA: [..]

          Nota Bene: a Notify payload is fully protected only in Quick Mode,
          where the entire payload is included in the HASH(n) digest.

        See responder_recv_*() in ike_quick_mode.c and RFC 2409 for details.

        Also if isakmpd receives "unexpected" hash payloads it does not
        verify them :-/.

      2.4
      
        When isakmpd receives a "delete message" in phase 2 ("delete
        messages" in phase 1 are ignored, see isakmpd_responder() in
        isakmp_doi.c) it does not check whether the origin of the "delete
        message" is the "owner" of the SA(s) to be deleted or in any other
        way authorized to delete the referenced SA(s). See
        ipsec_handle_leftover_payload() in ipsec.c for further details

        By the way: This behavior does NOT violate the RFCs, it is just a
        example of a bad local security policy. See RFC 2408, section 5.15.

      2.5

        For compatibility with some Cisco IPsec implementations isakmpd
        accepts phase 2 "delete messages" for ISAKMP SAs. See
        ipsec_delete_spi_list() in ipsec.c.

        This might not be a security issue or even a bug depending on your
        point of view, but it can be leveraged together with the other
        issues.

      Note: It is not required to take any action upon receipt of a "delete
      messages", but most IKE daemons do react by deleting the SA and so
      does isakmpd. RFC 2408, section 3.15:

        NOTE: The Delete Payload is not a request for the responder to
        delete an SA, but an advisory from the initiator to the responder.

    3 Affected Systems

      On 2003/09/02 2.1 and as a side effect 2.2 was fixed, i.e. isakmpd
      versions prior to 2003/09/02 include all issues listed above, newer
      versions "only" include the issues 2.{3,4,5}

      As isakmpd runs on a wide variety of platforms ({Open,Free,Net}BSD,
      MacOS X, Linux with FreeS/WAN's KLIPS, Linux 2.6) and is used in some
      appliances there might be some systems endangered due to these
      issues.

      Other IKE daemons are known to have similar issues, but AFAIK they
      cannot be leveraged to launch effective attacks.
      
    4 Leveraging the Issues

      There are many ways to "take advantage" of the issues described above.
      IMO the most severe thing to do is unauthorized IKE and/or IPsec SA
      deletion, because it is relatively easy to launch and has serious
      effects.

      4.1 pre 2003/09/02

        To delete an ISAKMP SA of your choice you only need to know the
        ISAKMP cookies and do some IP spoofing. If you want to delete an
        IPsec SA you need to know its SPI and whether it is for ESP or AH.
        http://thinknerd.de/~thomas/IPsec/delete-sa.c gives a clue how a
        "delete message" should look like.

      4.2 post 2003/09/02

        As of 2003/09/02 it is much harder to exploit the issues, because
        you need to send an encrypted "delete message". Therefore you need
        an ISAKMP SA with your victim. If you are a legitimate user or the
        like, you can try http://thinknerd.de/~thomas/IPsec/isakmpd+.diff on
        Linux 2.6.

    5. Bugfixes

      2.1 and 2.2 were fixed about 3 weeks after I have had reported the
      issues (see http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/isakmpd/
      message.c.diff?r1=1.60&r2=1.61&f=h). 2.{3,4,5} are still unfixed, but
      there are a few (OpenBSD) developers claiming to be working on this
      issue (for nearly 3 months). I hope that is not what they call
      "proactive security" ;-).

      As a temporary solution one could disable the reaction upon receipt of
      a "delete message".

    Thomas Walpuski

  • Next message: bugzilla_at_redhat.com: "[RHSA-2003:309-01] Updated fileutils/coreutils package fix ls vulnerabilities"