From ${URL} : Unlike IKEv2, in IKEv1 both ends retransmit. This leads to an amplification attack, since a single spoofed packet can trigger multiple retransmited packets. I believe the default case for libreswan would cause 6 packets to be sent. The initial packet, and retransmist at 0.5s, 1s, 2s, 4s, 8s and 16s, at which point we delete the failed state. I propose that the initial responder states for main mode and aggressive mode no longer retransmits, leaving retransmit responsibility for the initial packet at the initiator: diff --git a/programs/pluto/ikev1.c b/programs/pluto/ikev1.c index 67734df..329aac8 100644 --- a/programs/pluto/ikev1.c +++ b/programs/pluto/ikev1.c @@ -245,7 +245,7 @@ static const struct state_microcode v1_state_microcode_table[] = { { STATE_MAIN_R0, STATE_MAIN_R1, SMF_ALL_AUTH | SMF_REPLY, P(SA), P(VID) | P(CR), PT(NONE), - EVENT_v1_RETRANSMIT, main_inI1_outR1 }, + EVENT_NULL, main_inI1_outR1 }, /* STATE_MAIN_I1: R1 --> I2 * HDR, SA --> auth dependent @@ -394,7 +394,7 @@ static const struct state_microcode v1_state_microcode_table[] = { { STATE_AGGR_R0, STATE_AGGR_R1, SMF_PSK_AUTH | SMF_DS_AUTH | SMF_REPLY, P(SA) | P(KE) | P(NONCE) | P(ID), P(VID) | P(NATD_RFC), PT(NONE), - EVENT_v1_RETRANSMIT, aggr_inI1_outR1 }, + EVENT_NULL, aggr_inI1_outR1 }, /* STATE_AGGR_I1: * SMF_PSK_AUTH: HDR, SA, KE, Nr, IDir, HASH_R I don't think this would break any legitimate IKEv1 clients, since the initiator also will retransmit its initial packet. It would prevent libreswan from being abused to amplify an attack based on spoofed IKEv1 packets. @maintainer(s): since the fixed package is already in the tree, please let us know if it is ready for the stabilization or not.
Seems like a pretty minor issue, but we can stabilize it anyway.
amd64 stable
@x86, ping.
x86 stable. Maintainer(s), please cleanup.
CVE-2016-5361 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-5361): programs/pluto/ikev1.c in libreswan before 3.17 retransmits in initial-responder states, which allows remote attackers to cause a denial of service (traffic amplification) via a spoofed UDP packet. NOTE: the original behavior complies with the IKEv1 protocol, but has a required security update from the libreswan vendor; as of 2016-06-10, it is expected that several other IKEv1 implementations will have vendor-required security updates, with separate CVE IDs assigned to each.
GLSA Vote: No
