Bugzilla Bug 264346

==========================================================================
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 an attachment (id=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