CVE-2009-0790: ISAKMP DPD Remote Vulnerability with Openswan & Strongswan IPsec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 == 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 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 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 GPG key: 0xB5CC27E1 == -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEVAwUBSdDsnecYBqa1zCfhAQIgkQf9GGalx45xj5xmdXlSB/BZgRXhQW4fNWHp ZLLt5c40hOSvcmNfgYoIEz/QKpZPjfldvJ+c/08bAyAEQiHmmKkK+cFTlH1LtpDg 1f70lLrsziQ/eK1sQ9EYlFG4gbRfzjl1XZnnijAYvCAS1W12VSIU9gKN0YnHSCjH ndiGTxtYPEYhzm7QzraYPB28BqBqvdQcMMwbfTThjYHMowzt6fMzFEteCTqJ5YAT WgNbbbxBz1gNGssoiN4bv0YxaT+701OfKCdgJKKXs61We3twEQ2XKCi6l5Xw/lJe mrbVHYgUGy/ef70sN03O/vN5o+2If1n0Pib6usdeEcVA0L9RQOIW5A== =NxrM -END PGP SIGNATURE-
Re: [ GLSA 200903-18 ] Openswan: Insecure temporary file creation
On Mon, 9 Mar 2009, Robert Buchholz wrote: Subject: [ GLSA 200903-18 ] Openswan: Insecure temporary file creation Once again, thanks to everyone for not contacting the Openswan Project in this matter just like they did not do this 6 months ago when this "vulnerability" came out originally. Severity: Normal Title: Openswan: Insecure temporary file creation Date: March 09, 2009 Bugs: #238574 ID: 200903-18 An insecure temporary file usage has been reported in Openswan, allowing for symlink attacks. Dmitry E. Oboukhov reported that the IPSEC livetest tool does not handle the ipseclive.conn and ipsec.olts.remote.log temporary files securely. A local attacker could perform symlink attacks to execute arbitrary code and overwrite arbitrary files with the privileges of the user running the application. The ipsec livetest command was never called or used by anything in openswan as it was not finished. Furthermore, it was no longer installed AND explicitely disabled since: commit 4661d345b676d5412a52b6d1289568fc4ab31eac Author: Paul Wouters Date: Fri Nov 21 23:52:38 2008 -0600 Skip installing livetest when we added: $ head -5 programs/livetest/livetest.in #!/bin/sh echo "currently not used" exit Workaround == There is no known workaround at this time. The ipsec livetest is not even used by anything within the openswan software. It is never called. No parts of openswan are called without root privs. This whole thing is moot. Please bury it. Or just remove the install of the livetest command in your build environment. Or just ship a newer version of openswanm like 2.6.20 instead of the latest "vulnerable" version in 2.6.16. Resolution == All Openswan users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=net-misc/openswan-2.4.13-r2" Ahh. gentoo still uses the openswan-2.4.x version which has been EOL since early 2008. Also note that to problematic use was in wget -O. Perhaps one should talk to the wget people about symlink attack in their code instead? Paul
Re: Standing Up Against German Laws - Project HayNeedle
On Tue, 13 Nov 2007, Florian Echtler wrote: As a native German speaker, allow me to clarify: with respect to IP communication, the law mandates saving the following information for 6 months: - which customer was assigned which IP for what timespan - sender mail address, receiver mail address and sender IP for each mail - in case of VOIP: caller and callee phone number and IP address It's all in the ETSI version of the Transport of Intercepted IP Traffic (http://www.opentap.org/documents/TIIT-v1.0.0.pdf) and the "FuncSpec" document (http://www.opentap.org/documents/101WAI-GT-FuncspecV1.0.1.doc) They might have updated it by now. It used to treat email different from other traffic, but with IM now, I am sure that has changed. See http://www.opentap.org/documents/ for other documents So it wouldn't make much sense to create connection noise on a TCP or HTTP basis, as this stuff isn't logged. I think one should rather concentrate on generating email noise in this regard. Instead of creating noise, one should fix the problem of sending out plaintext email, and encourage people to use email encryption such as Enigma for Thunderbird. Encrypt IM conversations with OTR, and via other ways pro-actively protect ones own privacy. That is a real structural solution. Don't blame others for not using an envelope around your own communication. For pointers on how to obtain more privacy via userfriendly software, see: http://chameleon.spaink.net/PTT.pdf Paul
Re: [Full-disclosure] Microsoft DNS resolver: deliberately sabotagedhosts-file lookup
On Sat, 15 Apr 2006, Thor (Hammer of God) wrote: It's a simple method to bypass malicious host file modification. Probably in response to malware like MyDoom, which specifically altered the hosts file to keep clients from accessing AV sites ( go.microsoft.com was also specifically included in MyDoom as well.) Sure. And instead of everyone whining about this, they should prepare their DNSSEC setup so microsoft can secure their zone and can rely on the resolver to use DNSSEC to prevent these types of malware traps. Paul
Re: [ GLSA 200512-04 ] Openswan, IPsec-Tools: Vulnerabilities in ISAK MP Protocol implementation
On Mon, 12 Dec 2005, Thierry Carrez wrote: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200512-04 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: Openswan, IPsec-Tools: Vulnerabilities in ISAKMP Protocol implementation Date: December 12, 2005 Bugs: #112568, #113201 ID: 200512-04 Openswan and IPsec-Tools suffer from an implementation flaw which may allow a Denial of Service attack. That is correct (for openswan) Impact == A remote attacker can create a specially crafted packet using 3DES with an invalid key length, resulting in a Denial of Service attack, format string vulnerabilities or buffer overflows. That's a copy and paste from the IPsec proto testsuite. 1) It conflicts with the above comment that this is only a DOS 2) It's incorrect (for openswan) Workaround == Avoid using "aggressive mode" in ISAKMP Phase 1, which exchanges information between the sides before there is a secure channel. In fact, you would to both have aggressive mode enabled AND know the PSK. If you have those two enabled, you are vulnerable to a MITM anyway, since any client knowing the PSK can pretend to be the IPsec security gateway. Paul
