[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1037054: bullseye-pu: package libreswan/4.3-1+deb11u4



Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian.org@packages.debian.org
Usertags: pu
X-Debbugs-Cc: libreswan@packages.debian.org, dkg@fifthhorseman.net
Control: affects -1 + src:libreswan

[ Reason ]

Uploading libreswan 4.3-1+deb11u4 should address #1035542 (aka
CVE-2023-30570), which addresses a potential DoS against libreswan
instances that use a certain IKEv1 configuration.

Discussion with Salvatore Bonaccorso over in #1035542 concluded that
using point releases for this should be sufficient.

[ Impact ]

Users on bullseye with a specific libreswan configuration (IKEv1 in
aggressive mode) risk a DDoS on their libreswan IKE daemon if a
malicious attacker on the network emits a certain stream of packets.

[ Tests ]

Sadly, most libreswan test suites involve running virtual machines,
interacting with the linux kernel over open network policies, and this
isn't possible on debian testing architecture.

[ Risks ]

The risks of including these patches are minimal.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

The changes deal solely with how the pluto IKE daemon handles error
cases on incoming IKEv1 packets in aggressive mode.

[ Other info ]

All of the above information has been agregated and adapted from
https://libreswan.org/security/CVE-2023-30570/ Upstream released
version 4.11, which is just 4.10 with comparable patches applied.
4.11 is in unstable now.

I'll be uploading an update to 4.10 for a bookworm point release
shortly as well.
diff -Nru libreswan-4.3/debian/changelog libreswan-4.3/debian/changelog
--- libreswan-4.3/debian/changelog	2023-03-03 08:34:50.000000000 -0500
+++ libreswan-4.3/debian/changelog	2023-06-01 16:14:59.000000000 -0400
@@ -1,3 +1,9 @@
+libreswan (4.3-1+deb11u4) bullseye; urgency=medium
+
+  * Resolve CVE-2023-30570 (Closes: #1035542)
+
+ -- Daniel Kahn Gillmor <dkg@fifthhorseman.net>  Thu, 01 Jun 2023 16:14:59 -0400
+
 libreswan (4.3-1+deb11u3) bullseye-security; urgency=high
 
   * use upstream patch for 4.2 and 4.3
diff -Nru libreswan-4.3/debian/patches/0005-Resolve-CVE-2023-30570.patch libreswan-4.3/debian/patches/0005-Resolve-CVE-2023-30570.patch
--- libreswan-4.3/debian/patches/0005-Resolve-CVE-2023-30570.patch	1969-12-31 19:00:00.000000000 -0500
+++ libreswan-4.3/debian/patches/0005-Resolve-CVE-2023-30570.patch	2023-06-01 16:14:59.000000000 -0400
@@ -0,0 +1,140 @@
+From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
+Date: Thu, 1 Jun 2023 16:12:50 -0400
+Subject: Resolve CVE-2023-30570
+
+see https://libreswan.org/security/CVE-2023-30570/CVE-2023-30570.txt
+
+This patch was ported from
+https://libreswan.org/security/CVE-2023-30570/CVE-2023-30570-libreswan-4.x.patch
+---
+ programs/pluto/ikev1.c      | 60 ++++++++++++++++++++++++++++++++++++++++++---
+ programs/pluto/ikev1_aggr.c |  5 ++--
+ 2 files changed, 60 insertions(+), 5 deletions(-)
+
+diff --git a/programs/pluto/ikev1.c b/programs/pluto/ikev1.c
+index 2a06c2c..bb6c7be 100644
+--- a/programs/pluto/ikev1.c
++++ b/programs/pluto/ikev1.c
+@@ -1249,10 +1249,20 @@ void process_v1_packet(struct msg_digest *md)
+ 	struct state *st = NULL;
+ 	enum state_kind from_state = STATE_UNDEFINED;   /* state we started in */
+ 
++	/*
++	 * For the initial responses, don't leak the responder's SPI.
++	 * Hence the use of send_v1_notification_from_md().
++	 *
++	 * AGGR mode is a mess in that the R0->R1 transition happens
++	 * well before the transition succeeds.
++	 */
+ #define SEND_NOTIFICATION(t)						\
+ 	{								\
+ 		pstats(ikev1_sent_notifies_e, t);			\
+-		if (st != NULL)						\
++		if (st != NULL &&					\
++		    st->st_state->kind != STATE_AGGR_R0 &&		\
++		    st->st_state->kind != STATE_AGGR_R1 &&		\
++		    st->st_state->kind != STATE_MAIN_R0)		\
+ 			send_notification_from_state(st, from_state, t); \
+ 		else							\
+ 			send_notification_from_md(md, t);		\
+@@ -1322,17 +1332,26 @@ void process_v1_packet(struct msg_digest *md)
+ 			from_state = (md->hdr.isa_xchg == ISAKMP_XCHG_IDPROT ?
+ 				      STATE_MAIN_R0 : STATE_AGGR_R0);
+ 		} else {
+-			/* not an initial message */
++			/*
++			 * Possibly not an initial message.  Possibly
++			 * from initiator.  Possibly from responder.
++			 *
++			 * Possibly.  Which is probably hopeless.
++			 */
+ 
+ 			st = find_state_ikev1(&md->hdr.isa_ike_spis,
+ 					      md->hdr.isa_msgid);
+ 
+ 			if (st == NULL) {
+ 				/*
+-				 * perhaps this is a first message
++				 * Perhaps this is a first message
+ 				 * from the responder and contains a
+ 				 * responder cookie that we've not yet
+ 				 * seen.
++				 *
++				 * Perhaps this is a random message
++				 * with a bogus non-zero responder IKE
++				 * SPI.
+ 				 */
+ 				st = find_state_ikev1_init(&md->hdr.isa_ike_initiator_spi,
+ 							   md->hdr.isa_msgid);
+@@ -1343,6 +1362,21 @@ void process_v1_packet(struct msg_digest *md)
+ 					/* XXX Could send notification back */
+ 					return;
+ 				}
++				if (st->st_state->kind == STATE_AGGR_R0) {
++					/*
++					 * The only way for this to
++					 * happen is for the attacker
++					 * to guess the responder's
++					 * IKE SPI that hasn't been
++					 * sent over the wire?
++					 *
++					 * Well that or played 1/2^32
++					 * odds.
++					 */
++					log_pexpect(HERE,
++						     "phase 1 message matching AGGR_R0 state");
++					return;
++				}
+ 			}
+ 			from_state = st->st_state->kind;
+ 		}
+@@ -3027,6 +3061,26 @@ void complete_v1_state_transition(struct state *st, struct msg_digest *md, stf_s
+ 			delete_state(st);
+ 			/* wipe out dangling pointer to st */
+ 			md->st = NULL;
++		} else if  (st->st_state->kind == STATE_AGGR_R0 ||
++			    st->st_state->kind == STATE_AGGR_R1 ||
++			    st->st_state->kind == STATE_MAIN_R0) {
++			/*
++			 *
++			 * Wipe out the incomplete larval state.
++			 *
++			 * ARGH! In <=v4.10, the aggr code flipped the
++			 * larval state to R1 right at the start of
++			 * the transition and not the end, so using
++			 * state to figure things out is close to
++			 * useless.
++			 *
++			 * Deleting the state means that pluto has no
++			 * way to detect and ignore amplification
++			 * attacks.
++			 */
++			delete_state(st);
++			/* wipe out dangling pointer to st */
++			md->st = NULL;
+ 		}
+ 		break;
+ 	}
+diff --git a/programs/pluto/ikev1_aggr.c b/programs/pluto/ikev1_aggr.c
+index 98f6ba8..d4cb115 100644
+--- a/programs/pluto/ikev1_aggr.c
++++ b/programs/pluto/ikev1_aggr.c
+@@ -161,7 +161,7 @@ stf_status aggr_inI1_outR1(struct state *unused_st UNUSED,
+ 	struct ike_sa *ike = new_v1_rstate(c, md);
+ 	struct state *st = &ike->sa;
+ 	md->st = st;  /* (caller will reset cur_state) */
+-	change_state(st, STATE_AGGR_R1);
++	change_state(st, STATE_AGGR_R0);
+ 
+ 	/* warn for especially dangerous Aggressive Mode and PSK */
+ 	if (LIN(POLICY_PSK, c->policy) && LIN(POLICY_AGGRESSIVE, c->policy)) {
+@@ -178,7 +178,8 @@ stf_status aggr_inI1_outR1(struct state *unused_st UNUSED,
+ 
+ 	if (!v1_decode_certs(md)) {
+ 		log_state(RC_LOG, st, "X509: CERT payload bogus or revoked");
+-		return false;
++                /* XXX notification is in order! */
++		return STF_FAIL + INVALID_ID_INFORMATION;
+ 	}
+ 
+ 	/*
diff -Nru libreswan-4.3/debian/patches/series libreswan-4.3/debian/patches/series
--- libreswan-4.3/debian/patches/series	2023-03-03 08:30:19.000000000 -0500
+++ libreswan-4.3/debian/patches/series	2023-06-01 16:13:36.000000000 -0400
@@ -2,3 +2,4 @@
 0002-debian-pam.d-pluto.patch
 CVE-2022-23094.patch
 CVE-2023-23009-libreswan-4.2-4.3.patch
+0005-Resolve-CVE-2023-30570.patch

Reply to: