10922203 2003-11-02 22:08 +0100 /141 rader/ Thomas Walpuski <thomas@thinknerd.de>
Importerad: 2003-11-03 19:55 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <29738>
Ärende: multiple payload handling flaws in isakmpd
------------------------------------------------------------
From: Thomas Walpuski <thomas@thinknerd.de>
To: bugtraq@securityfocus.com
Message-ID: <20031102210826.GA16663@thinknerd.de>
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
(10922203) /Thomas Walpuski <thomas@thinknerd.de>/(Ombruten)
Kommentar i text 10941813 av Thomas Walpuski <thomas@thinknerd.de>
10941813 2003-11-07 16:44 +0100 /18 rader/ Thomas Walpuski <thomas@thinknerd.de>
Importerad: 2003-11-07 21:17 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <29798>
Kommentar till text 10922203 av Thomas Walpuski <thomas@thinknerd.de>
Ärende: Re: multiple payload handling flaws in isakmpd
------------------------------------------------------------
From: Thomas Walpuski <thomas@thinknerd.de>
To: bugtraq@securityfocus.com
Message-ID: <20031107154427.GA983@thinknerd.de>
About 23h ago Hakan Olsson commited a patch by Hans-Jörg Höxer to CVS,
which fixes the issues mentioned in section 2.1¹ and 2.3. For detailed
information see http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/isakmpd/
{exchange.c.diff?r1=1.86&r2=1.87,exchange.c.diff?r1=1.86&r2=1.87}.
The issue described in section 2.4 still remains unfixed. As this is
crucial for the feasibility of the attack mentioned in section 4.2,
the whole thing is still quite bad.
Thomas Walpuski
1 - So far 2.1 was fixed for phase 2 exchanges only.
(10941813) /Thomas Walpuski <thomas@thinknerd.de>/(Ombruten)