From fb5a398781827e4b643a437ac253ff224fbbd7ea Mon Sep 17 00:00:00 2001 From: CentOS Sources Date: Tue, 16 May 2023 10:20:54 +0000 Subject: [PATCH] import libreswan-4.9-3.el8_8 --- SOURCES/libreswan-4.9-cve-2023-30570.patch | 129 +++++++++++++++++++++ SPECS/libreswan.spec | 9 +- 2 files changed, 137 insertions(+), 1 deletion(-) create mode 100644 SOURCES/libreswan-4.9-cve-2023-30570.patch diff --git a/SOURCES/libreswan-4.9-cve-2023-30570.patch b/SOURCES/libreswan-4.9-cve-2023-30570.patch new file mode 100644 index 0000000..d175506 --- /dev/null +++ b/SOURCES/libreswan-4.9-cve-2023-30570.patch @@ -0,0 +1,129 @@ +diff --git a/programs/pluto/ikev1.c b/programs/pluto/ikev1.c +index e0615323ed..401618b6dd 100644 +--- a/programs/pluto/ikev1.c ++++ b/programs/pluto/ikev1.c +@@ -1101,10 +1101,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_v1_notification_from_state(st, from_state, t); \ + else \ + send_v1_notification_from_md(md, t); \ +@@ -1168,17 +1178,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); +@@ -1189,6 +1208,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. ++ */ ++ llog_pexpect(md->md_logger, HERE, ++ "phase 1 message matching AGGR_R0 state"); ++ return; ++ } + } + from_state = st->st_state->kind; + } +@@ -2870,7 +2904,28 @@ void complete_v1_state_transition(struct state *st, struct msg_digest *md, stf_s + delete_state(st); + /* wipe out dangling pointer to st */ + md->v1_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->v1_st = NULL; + } ++ + break; + } + } +diff --git a/programs/pluto/ikev1_aggr.c b/programs/pluto/ikev1_aggr.c +index 2732951beb..87be80cb6c 100644 +--- a/programs/pluto/ikev1_aggr.c ++++ b/programs/pluto/ikev1_aggr.c +@@ -169,7 +169,7 @@ stf_status aggr_inI1_outR1(struct state *null_st UNUSED, + /* Set up state */ + struct ike_sa *ike = new_v1_rstate(c, md); + md->v1_st = &ike->sa; /* (caller will reset cur_state) */ +- change_v1_state(&ike->sa, STATE_AGGR_R1); ++ change_v1_state(&ike->sa, STATE_AGGR_R0); + + /* + * Warn when peer is expected to use especially dangerous +@@ -197,7 +197,8 @@ stf_status aggr_inI1_outR1(struct state *null_st UNUSED, + + if (!v1_decode_certs(md)) { + llog_sa(RC_LOG, ike, "X509: CERT payload bogus or revoked"); +- return false; ++ /* XXX notification is in order! */ ++ return STF_FAIL_v1N + v1N_INVALID_ID_INFORMATION; + } + + /* diff --git a/SPECS/libreswan.spec b/SPECS/libreswan.spec index e40912d..f50c3c5 100644 --- a/SPECS/libreswan.spec +++ b/SPECS/libreswan.spec @@ -37,7 +37,7 @@ Name: libreswan Summary: IPsec implementation with IKEv1 and IKEv2 keying protocols # version is generated in the release script Version: 4.9 -Release: %{?prever:0.}2%{?prever:.%{prever}}%{?dist}.2 +Release: %{?prever:0.}3%{?prever:.%{prever}}%{?dist} License: GPLv2 Url: https://libreswan.org/ @@ -54,6 +54,7 @@ Patch3: libreswan-4.1-maintain-obsolete-keywords.patch Patch6: libreswan-4.3-1934186-config.patch Patch7: libreswan-4.9-cve-2023-23009.patch Patch8: libreswan-4.9-2176248-authby-rsasig.patch +Patch9: libreswan-4.9-cve-2023-30570.patch BuildRequires: audit-libs-devel BuildRequires: bison @@ -114,6 +115,7 @@ Libreswan is based on Openswan-2.6.38 which in turn is based on FreeS/WAN-2.04 %patch6 -p1 %patch7 -p1 %patch8 -p1 +%patch9 -p1 # linking to freebl is not needed sed -i "s/-lfreebl //" mk/config.mk @@ -217,6 +219,11 @@ certutil -N -d sql:$tmpdir --empty-password %attr(0644,root,root) %doc %{_mandir}/*/* %changelog +* Fri May 05 2023 Sahana Prasad - 4.9-3 +- Fix CVE-2023-30570: Malicious IKEv1 Aggressive Mode packets can crash + libreswan +- Resolves: rhbz#2187179 + * Tue Apr 25 2023 Daiki Ueno - 4.9-2.2 - Update libreswan-4.9-2176248-authby-rsasig.patch