Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 113201 - net-firewall/ipsec-tools: Denial of Service in aggressive mode
Summary: net-firewall/ipsec-tools: Denial of Service in aggressive mode
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High minor (vote)
Assignee: Gentoo Security
Whiteboard: C3 [glsa]
Depends on:
Reported: 2005-11-21 14:18 UTC by Sune Kloppenborg Jeppesen (RETIRED)
Modified: 2005-12-12 06:55 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---

patch output (ipsec-tools-0.6.2-dos-fix.diff-15356.out,3.28 KB, text/plain)
2005-12-03 02:56 UTC, Simon Stelling (RETIRED)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-11-21 14:18:17 UTC
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 
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 
Comment 1 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-11-21 14:19:21 UTC
Patch that fix the issue is available here: 
Comment 2 Thierry Carrez (RETIRED) gentoo-dev 2005-11-22 00:55:28 UTC
Ccing maintainer
Comment 3 Thierry Carrez (RETIRED) gentoo-dev 2005-11-30 08:08:05 UTC
    IPsec-tools 0.6.3 released and contains fixes for various DoS problems

Maintainer: please bump or apply patch.
Comment 4 Peter Johanson (RETIRED) gentoo-dev 2005-12-02 01:20:32 UTC
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)
Comment 5 Thierry Carrez (RETIRED) gentoo-dev 2005-12-02 01:23:29 UTC
Archs please test and mark 0.6.2-r1 stable
Comment 6 Jason Wever (RETIRED) gentoo-dev 2005-12-02 16:11:20 UTC
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.
Comment 7 Thierry Carrez (RETIRED) gentoo-dev 2005-12-03 01:59:32 UTC
Back to ebuild to bump 0.4 for sparc.
x86/amd64 should still mark 0.6.2-r1 stable.
Comment 8 Simon Stelling (RETIRED) gentoo-dev 2005-12-03 02:55:06 UTC
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
Comment 9 Simon Stelling (RETIRED) gentoo-dev 2005-12-03 02:56:37 UTC
Created attachment 73976 [details]
patch output
Comment 10 Peter Johanson (RETIRED) gentoo-dev 2005-12-03 11:24:33 UTC
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.
Comment 11 Peter Johanson (RETIRED) gentoo-dev 2005-12-03 11:34:54 UTC
Weeve: Ok, you've got 0.4-r2 in portage now with the included fix.
Comment 12 Simon Stelling (RETIRED) gentoo-dev 2005-12-04 05:33:25 UTC
looks fine on amd64 now
Comment 13 Jason Wever (RETIRED) gentoo-dev 2005-12-04 12:20:56 UTC
0.4-r2 stable on SPARC
Comment 14 Peter Johanson (RETIRED) gentoo-dev 2005-12-04 14:23:03 UTC
Marked 0.6.2-r2 stable on x86 (and removing their CC) at Halcy0n's request.
Comment 15 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-12-05 12:50:53 UTC
This one is ready for GLSA vote. I tend to vote NO. 
Comment 16 Thierry Carrez (RETIRED) gentoo-dev 2005-12-06 04:54:39 UTC
We should do one since we do one with openswan... which is the same
vulnerability. Maybe a grouped one ?
Comment 17 Thierry Carrez (RETIRED) gentoo-dev 2005-12-09 07:02:02 UTC
Grouped GLSA drafted. Just needs another review.
Comment 18 Thierry Carrez (RETIRED) gentoo-dev 2005-12-12 06:55:06 UTC
GLSA 200512-04