========================================================================== Openswan & Strongswan Security Notification March 30, 2009 Remote DoS Vulnerability in Openswan & Strongswan IPsec CVE-2009-0790 ========================================================================== A vulnerability in the Dead Peer Detection (RFC-3706) code was found by Gerd v. Egidy <gerd.von.egidy@intra2net.com> of Intra2net AG affecting all Openswan and all Strongswan releases. A malicious (or expired ISAKMP) R_U_THERE or R_U_THERE_ACK Dead Peer Detection packet can cause the pluto IKE daemon to crash and restart. No authentication or encryption is required to trigger this bug. One spoofed UDP packet can cause the pluto IKE daemon to restart and be unresponsive for a few seconds while restarting. A patch was created by Paul Wouters <paul@xelerance.com> for Openswan and Strongswan. This bug affects the following software releases: Current branches: Openswan-2.6.20 and earlier Strongswan-4.2.13 and earlier Maintenance mode branches: Openswan-2.4.13 and earlier Strongswan-2.8.8 and earlier End of Life branches: Superfreeswan-1.9x Openswan-1.x Openswan-2.0.x - 2.3.1 Openswan-2.5.x Everyone is strongly encouraged to upgrade to these minimum versions: openswan-2.6.21 strongswan-4.2.14 openswan-2.4.14 strongswan-2.8.9 If you cannot upgrade to a new version, please apply the appropriate patch as listed at http://www.openswan.org/CVE-2009-0790/ Dead Peer Detection is an IPsec IKE Notification message. It uses an ICOOKIE/RCOOKIE mechanism to match an incoming packet to a know Security Association (ISAKMP). Unlike most Notification messages, DPD notifications have no phase2 state association. Incorrect handling of this exception can cause a NULL pointer dereference on a non-existing state object 'st'. This bug is triggered in the case where one end has expired an ISAKMP state, but the other end still uses the old state to send a DPD Notification. Since this state-lookup is performed before any encryption or decryption takes place, as we need to find the proper ISAKMP to locate the cryptogrpahic key material used for decryption, this bug can be triggered without going through a phase1 (ISAKMP) negotiation. When such a packet is received, the pluto daemon crashes and restarts. Locations for downloading patches and source code: http://www.openswan.org/ http://www.strongswan.org/ ftp://ftp.openswan.org/openswan/ http://download1.strongswan.org/ ftp://ftp.openswan.fi/pub/openswan/ http://download2.strongswan.org/ Paul Wouters <paul@xelerance.com> GPG key: 0xB5CC27E1 ========================================================================== Reproducible: Always
Robin, I cc'd you as you did the last bumps for strongswan, maybe you feel like bumping/patching this time, too. All: Please either bump or apply the patches here: http://www.openswan.org/CVE-2009-0790/
Created attachment 187273 [details] version bump test on amd64: - kernel 2.6.28 looks good - xen DomU kernel 2.6.18 does not work
I've bumped openswan to the new versions. amd64 & x86 teams, please stabilize net-misc/openswan-2.4.14.
(In reply to comment #3) > I've bumped openswan to the new versions. > > amd64 & x86 teams, please stabilize net-misc/openswan-2.4.14. > openswan-2.4.14-gentoo.patch fails to apply.
(In reply to comment #4) > (In reply to comment #3) > > I've bumped openswan to the new versions. > > > > amd64 & x86 teams, please stabilize net-misc/openswan-2.4.14. > > > > openswan-2.4.14-gentoo.patch fails to apply. > line 54 should be: # RCSID $Id: ipsec.conf.in,v 1.15.2.6 2006-10-19 03:49:46 paul Exp $ unless you plan to change that to reflect the edit. Sorry for the double post.
Resynchronize your tree. This issue has been fixed days ago.
(In reply to comment #6) > Resynchronize your tree. This issue has been fixed days ago. I synced maybe an hour ago and it still fails here... >>> Source unpacked in /var/tmp/portage/net-misc/openswan-2.4.14/work * Applying openswan-2.4.14-gentoo.patch ... * Failed Patch: openswan-2.4.14-gentoo.patch ! * ( /usr/portage/net-misc/openswan/files/openswan-2.4.14-gentoo.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/net-misc/openswan-2.4.14/temp/openswan-2.4.14-gentoo.patch-26405.out
I tried to fix it by running cvs update -kb, but cvs seems unable to add flags to existing files, so I've replaced the gentoo.patch with gentoo-fixed.patch (this time added with -kb). Sorry for the troble... Did I mentioned I hate cvs?
mrness: fyi for future. if you fail to add a file with -kb the first time, you must do this to fix it: cvs rm -f $file ; cvs ci $file ; cvs add -kb ; repoman commit .... The commit in the middle is not optional.
amd64/x86 stable, all arches done.
Ready for vote, I vote YES.
+*strongswan-4.2.15 (07 Jun 2009) + + 07 Jun 2009; Robert Buchholz <rbu@gentoo.org> +strongswan-4.2.15.ebuild: + Version bump, fixes security bug 264346 and 272276. Remove old warning in + the code, fix dependencies and configure options. Comment in user and group + specification again. Added some TODOs. strongswan is ~arch only.
Yes, too. Request filed.
FAIL. Closing noglsa, of course.
let's track this as open until the glsa for openswan is out.
Sure. I apologize, I saw #12 and #13 and thought I had made a mistake, I didn't look hard enough. :(
GLSA 200909-05
