Hi all. A few days ago, we had lots of discussions about the "PROTOS" IKE test suite [1], and about a global "IKE implementations vulnerabilities". Adrian Portelli from NetBSD team reported us three test cases which could lead to a racoon crash (access to a NULL pointer). I could only reproduce one of them on my own test configuration, for unknown reasons. A few details about those test cases: 1) All three are based on AGGRESSIVE mode. 2) All three require a very weak racoon configuration (no lifetime proposal or obey mode). 3) All three require racoon's configuration to be 3DES/SHA1/DH2. 4) All three DO NOT require valid identifier/PSK Note that conditions 2 and 3 are just specific to the test suite which was used, other programs may have other default proposals or may bruteforce various proposals. The two crashes heppens because there was no check in aggressive mode code to ensure that we got specific payloads from the peer. The IKE exchanges don't provide those payloads, pointers stays NULL, and we have a crash later in the code when trying to access NULL memory. Payload existency check was already present in main mode. So the problem is "minor", as it can "just" lead to a racoon crash, and as it requires a configuration which is quite weak, which is known to have some other security problems, and which should NOT be used ! On friday, I sent a first mail on the lists to see if people needed some time to generate new packages, but I had no answers. So I just commited the fix on HEAD and Branch 0.6 (if people needs it on other branchs, it's trivial to backport). It will be included in version 0.6.3, which should be released very quickly. Adrian and I both ran all the test suite without noticing any other problems. [1] http://www.ee.oulu.fi/research/ouspg/protos/testing/c09/isakmp Yvan.
Patch that fix the issue is available here: http://cvs.sourceforge.net/viewcvs.py/ipsec-tools/ipsec-tools/src/racoon/isakmp_agg.c?r1=1.20.2.3&r2=1.20.2.4
Ccing maintainer
From http://ipsec-tools.sourceforge.net/ 2005-11-21 IPsec-tools 0.6.3 released and contains fixes for various DoS problems Maintainer: please bump or apply patch.
0.6.3 is bumped in portage and I've added 0.6.2-r1 to portage that includes the patch. Since 0.6.2 has been in the tree an acceptible time, and has proven fine for my use, I suggest we move for the three affected arches to mark 0.6.2-r1 stable on all 3 arches to get the fix pushed to users. (Will leave security folks to CCing arches if they agree on course of action)
Archs please test and mark 0.6.2-r1 stable
On SPARC, we'll need a bumped version of 0.4 (due to us not having 2.6 headers available in the default profiles). The first hunk in the patch fails (which is OK since its just comments) but the 2nd and 3rd apply fine, so with a little touch-up it should apply easily.
Back to ebuild to bump 0.4 for sparc. x86/amd64 should still mark 0.6.2-r1 stable.
at least on amd64: * Applying ipsec-tools-0.6.2-dos-fix.diff ... * Failed Patch: ipsec-tools-0.6.2-dos-fix.diff ! * ( /usr/portage/net-firewall/ipsec-tools/files/ipsec-tools-0.6.2-dos-fix.diff ) will attach the log
Created attachment 73976 [details] patch output
Argh. The patch got borked by the CVS commit, since there was an $Id$ header from the patch I pulled from SF CVS. Sorry about that, it's fixed in portage now.
Weeve: Ok, you've got 0.4-r2 in portage now with the included fix.
looks fine on amd64 now
0.4-r2 stable on SPARC
Marked 0.6.2-r2 stable on x86 (and removing their CC) at Halcy0n's request.
This one is ready for GLSA vote. I tend to vote NO.
We should do one since we do one with openswan... which is the same vulnerability. Maybe a grouped one ?
Grouped GLSA drafted. Just needs another review.
GLSA 200512-04