Bugzilla Bug 113201

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 an attachment (id=73976) [edit]
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