Bug 1308508 (CVE-2016-5361) - CVE-2016-5361 IKEv1 protocol is vulnerable to DoS amplification attack
Summary: CVE-2016-5361 IKEv1 protocol is vulnerable to DoS amplification attack
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2016-5361
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1344566 1344567
Blocks: 1308512
TreeView+ depends on / blocked
 
Reported: 2016-02-15 12:32 UTC by Adam Mariš
Modified: 2019-09-29 13:44 UTC (History)
5 users (show)

Fixed In Version: libreswan 3.17
Doc Type: Bug Fix
Doc Text:
A traffic amplification flaw was found in the Internet Key Exchange version 1 (IKEv1) protocol. A remote attacker could use a libreswan server with IKEv1 enabled in a network traffic amplification denial of service attack against other hosts on the network by sending UDP packets with a spoofed source address to that server.
Clone Of:
Environment:
Last Closed: 2019-07-12 13:04:06 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2603 normal SHIPPED_LIVE Moderate: libreswan security and bug fix update 2016-11-03 12:13:02 UTC

Description Adam Mariš 2016-02-15 12:32:52 UTC
It was reported that IKE/IKEv2 protocol is vulnerable to DoS amplification attack.

Comment 2 Paul Wouters 2016-02-16 21:15:50 UTC
Some comments:

"The first is that a proper IKE_SA_INIT packet will result in an unknown number of packets from the responder over an unspecified period of time."

This is incorrect. IKEv2 responders _never_ retransmit. So for each received IKE_INIT request it will send at most one IKE_INIT response. Which you noticed too:

"A majority of these (3.9 million) only replied with a single packet"

Next:

"The second is that the responder is expecting abuse and will not maintain any state related to unauthenticated peers.  What this tells us in theory is that IKE infrastructure as designed might be susceptible to abuse for the sake of reflection and amplification DDoS attacks."

I do not understand this remark. Any server exposed to the internet should be designed against DDoS attacks. The IKEv2 protocol does this very well. libreswan supports this with various ddos- options that can be tweaked when needed, but provides sane defaults.

Next:

"These standards say that the sender of a packet should set a timer and a counter, and upon failure of a response packet, they should attempt a packet retransmission.  These  retransmissions should be sent using an exponential back­off and should continue retransmission until the counter is exhausted or a reply is received."

That is clearly only valid for IKEv1. For IKEv1, we use exponential back-off. In all openswan versions this was 20s, 40s, 60s, 60s... For libreswan this is 0.5s, 1s, 2s, 4s, 8s, 16s. The timeout for openswan was 5 minutes, for libreswan it is 30 seconds.

"ultimately triggering an amplification ranging from 2%  to 7,933%"

These numbers of out real context, don't mean much.

"In this traffic sample a host configured to respond 10 times was targeted at random of all 10 count hosts, it was sent a packet with a randomized SPI every .1 seconds for a total of 100 packets. "

This makes no sense. You configured a host to reply 10 times? Well, that's not a valid IKEv2 host then, so your custom protocol can amplify 10 times?

"The easiest and suggested way to mitigate this attack would be a blanket policy dropping all inbound UDP traffic sourcing from port 500 where possible."

That would be blocking legitimate IKE traffic. Why would you do that? It would break any device attempting to use IKE/IPsec.

"If the affected machine is another IKEv2 node that requires port  500 be open for operational purposes rate limiting that ultimately leads to blocking would be the next best option."

"A rate limiting strategy is recommended,"

See "man ipsec.conf" and look for ddos-mode, ddos-ike-treshold and max-halfopen-ike

"However, we also know that a  single request can trigger multiple responses over fairly long windows of time"

Not for openswan/libreswan. Especially not in IKEv2.

"Another option and likely more successful strategy would be utilizing outbound rate­limiting and dropping outbound traffic.  Preferably both of these measures could be combined to help prevent your infrastructure from being leveraged for DDoS abuse. "

Nothing should be done outside of /etc/ipsec.conf configuration. And even there the defaults are very sane.

" In their current state we believe they could be leveraged to attack those same businesses and organizations around the Internet with crippling success."

I suggest you take it up to the IETF to obsolete the UDP protocol and find a replacement with the same features we need from UDP that lacks the downsides of UDP. I wish you good luck :)

I would like to close this bug as WONTFIX

Comment 4 Huzaifa S. Sidhpurwala 2016-03-14 06:39:07 UTC
Statement:

This is a protocol flaw which affects IKEv1. All complaint implementations are therefore affected by this flaw. Red Hat Product Security team, does not consider IKEv2 to be affected. For more details please refer to https://bugzilla.redhat.com/show_bug.cgi?id=1308508#c2

Comment 5 Paul Wouters 2016-03-14 11:05:33 UTC
Re-opening, I'll write upa blog post on this.

We are considering one update to libreswan IKEv1 to reduce amplification caused by retransmits:

https://lists.libreswan.org/pipermail/swan-dev/2016-March/001394.html

For IKEv2, there is no such issue (and IKE_INIT response is smaller than IKE_INIT reply message.

Comment 6 Huzaifa S. Sidhpurwala 2016-06-10 04:25:04 UTC
This is tracked via upstream bug:

https://bugs.libreswan.org/show_bug.cgi?id=262

Comment 7 Huzaifa S. Sidhpurwala 2016-06-10 04:33:24 UTC
Upstream commit:

https://github.com/libreswan/libreswan/commit/152d6d95632d8b9477c170f1de99bcd86d7fb1d6

Comment 8 Huzaifa S. Sidhpurwala 2016-06-10 04:50:44 UTC
Created libreswan tracking bugs for this issue:

Affects: fedora-all [bug 1344566]

Comment 10 Huzaifa S. Sidhpurwala 2016-06-10 05:15:43 UTC
CVE request:

http://seclists.org/oss-sec/2016/q2/515

Comment 11 Paul Wouters 2016-06-10 13:32:34 UTC
note this is fixed in libreswan 3.17

Comment 12 Andrej Nemec 2016-06-10 14:05:51 UTC
CVE assignment:

http://seclists.org/oss-sec/2016/q2/518

This CVE is specifically for the issue in libreswan, as confirmed by Mitre:

"Use CVE-2016-5361 for this issue only in the libreswan codebase."

Comment 13 Paul Wouters 2016-06-10 14:32:12 UTC

The issue is a protocol issue, not a libreswan code implementation issue.

Comment 14 Tuomo Soini 2016-06-10 15:11:03 UTC
Please remove this CVE immediately. That is not a security vulnerability in libreswan.

Comment 15 Huzaifa S. Sidhpurwala 2016-06-13 04:23:06 UTC
(In reply to Tuomo Soini from comment #14)
> Please remove this CVE immediately. That is not a security vulnerability in
> libreswan.

Hi Tuomo, 

Please talk with MITRE about this (They assigned the CVE!). If you note comment #10, i actually asked for a CVE pertaining to the IKE protocol flaw, rather than its implementation.

Comment 16 Tuomo Soini 2016-06-13 05:18:00 UTC
Redhat security requested this CVE - you should admit your mistake and request removal.

Please contact security@libreswan.org before requesting CVE:s for libreswan. This is not first total bogus cve requested by redhat security and you should not request these without contacting us.

Tuomo Soini,
The Librewan Project

Comment 18 Martin Prpič 2016-07-08 06:48:12 UTC
IKEv2 is reported to be affected as well:

http://seclists.org/oss-sec/2016/q3/23

Comment 19 Paul Wouters 2016-07-08 08:17:43 UTC
See my reply on the list. I think those are most likely IKEv1 only implementations using the incoming ISAKMP haeder to build a reply packet.

Comment 22 errata-xmlrpc 2016-11-03 21:22:46 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2016:2603 https://rhn.redhat.com/errata/RHSA-2016-2603.html

Comment 25 Product Security DevOps Team 2019-07-12 13:04:06 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2016-5361


Note You need to log in before you can comment on or make changes to this bug.