A few days ago, we had lots of discussions about the "PROTOS" IKE test
suite , 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
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
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
Patch that fix the issue is available here:
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]
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.