Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Security)  >   isakmpd Vendors:   OpenBSD
OpenBSD ISAKMP Daemon (isakmpd) May Let Remote Users Delete Arbitrary Security Associations
SecurityTracker Alert ID:  1008086
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Nov 3 2003
Impact:   Modification of system information

Description:   Some vulnerabilities were reported in the OpenBSD ISAKMP daemon (isakmpd). A remote user may be able to cause denial of service conditions.

It is reported that the software contains flaws in the processing of delete payloads that may allow a remote user to delete IKE and IPSec security associations (SAs).

The report indicated that, in Quick Mode, isakmpd does not require message encryption. Some Main Mode messages are also affected.

It is reported that isakmpd does not use payload encryption when responding in Quick Mode when the initiator did not apply payload encryption.

It is also reported that isakmpd will accept a Phase 2 message that contains a delete payload but not a hash payload.

It is also reported that "unexpected" hash payloads are not verified.

It is also reported that when the target isakmpd server receives a delete payload during Phase 2 negotiation, the server does not validate whether the sender is the owner of the referenced SA.

Impact:   A remote user may be able to generate a message to cause a security association to be deleted by the target isakmpd process.
Solution:   It is reported that the vendor issued a fix for the Quick Mode encryption flaws on September 2, 2003.

No solution for the remaining flaws was available at the time of this entry.

Vendor URL: (Links to External Site)
Cause:   Authentication error
Underlying OS:  UNIX (FreeBSD), UNIX (NetBSD), UNIX (OpenBSD)

Message History:   This archive entry has one or more follow-up message(s) listed below.
Nov 7 2003 (Partial Fix is Available) Re: OpenBSD ISAKMP Daemon (isakmpd) May Let Remote Users Delete Arbitrary Security Associations
A fix has been released for some of the reported flaws.
Jan 14 2004 (Vendor Issues Fix) OpenBSD ISAKMP Daemon (isakmpd) May Let Remote Users Delete Arbitrary Security Associations
The vendor has issued a fix.
Jun 11 2004 (Software Still Vulnerable) OpenBSD ISAKMP Daemon (isakmpd) May Let Remote Users Delete Arbitrary Security Associations
The software is still vulnerble.
Jun 11 2004 (Another Patch is Available) OpenBSD ISAKMP Daemon (isakmpd) May Let Remote Users Delete Arbitrary Security Associations
OpenBSD has issued a fix.

 Source Message Contents

Subject:  multiple payload handling flaws in isakmpd

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

    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

    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

    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


    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 :-/.

    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.


    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

  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

  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

  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. 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 on
    Linux 2.6.

5. Bugfixes

  2.1 and 2.2 were fixed about 3 weeks after I have had reported the
  issues (see
  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


Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, LLC