Bugzilla – Bug 64726
VUL-0: CVE-2005-0398: ipsectools/racoon
Last modified: 2021-10-19 14:02:23 UTC
Started auditing racoon, the isakmp daemon of ipsectools. Generally good code, just the parsing of ISAKMP generic headers makes some problems. This entry is mainly for myself to keep track. Some interesting points so far: ipsec_doi.c:1293: - (sizeof(struct isakmp_pl_p) + prop->spi_size); //AUD isakmp.c:1208: *///AUD: result nicht mit 0 geclesned. kann noch pakete von let ztem mal beinhalten?? /Da calloc() benutzt wird, nein isakmp.c:1234: p->len = ntohs(gen->len);//AUD: but p->len could be < si zeof(isakmp_gen) and subtractions will yield < 0 later isakmp.c:1241: p->ptr = gen; //AUD: flat copy?? isakmp.c:1262: gen = (struct isakmp_gen *)((caddr_t)gen + plen);//AUD isakmp.c:2185: //AUD: vamlloc calls calloc() which could alloc 0 bytes isakmp.c:2192: memcpy((*buf)->v, gen + 1, (*buf)->l);//AUD: crash. isakmp_base.c:495: case ISAKMP_NPTYPE_HASH://AUD: pl_hash from net, contains gen hdr with length field passed thru plogdump() isakmp_quick.c:380: + ntohl(isakmp->len) - sizeof(*isakmp);//AUD isakmp_quick.c:400: memcpy(p, pa->ptr, pa->len);//AUD! isakmp_quick.c:490: plog(LLV_DEBUG, LOCATION, NULL, "HASH(2) received:");//A UD: isakmp_quick.c:759: plog(LLV_DEBUG, LOCATION, NULL, "HASH(4) validate:");//A UD isakmp_quick.c:894: hbuf = vmalloc(tlen);//AUD isakmp_quick.c:1026: plog(LLV_DEBUG, LOCATION, NULL, "HASH(1) validate:");//A UD oakley.c:1211: plogdump(LLV_DEBUG, r_hash,//AUD: may be < 0 plog.c:188: buflen = (len * 2) + (len / 4) + (len / 32) + 3;//AUD It seems as the VPN gateway can be crashed if allocating of more than 1.2Gig is successfull because then it tries to read such amount of data from packet. Its pre-authentication. isakmp_main(msg) { ph1_main(iph1, msg) { base_i3recv(ph1handle * iph1, vchar_t *msg) { pa = isakmp_parse(msg) { isakmp_parsewoh(msg + sizeof(*isakmp)) { zerlegt buffer in array generischer ISAKMP pakete p->ptr = gen } } iph1->pl_hash = (struct isakmp_pl_hash *)pa->ptr; oakley_validate_auth(iph1) { plogdump(LLV_DEBUG, r_hash, ntohs(iph1->pl_hash->h.len) - sizeof(*iph1->pl_hash));{ ... buflen = (len * 2) + (len / 4) + (len / 32) + 3; buf = racoon_malloc(buflen); ... } } } } Base-mode affected so far. Did not check others yet. Not only Initiator, also responder functions are affected. So its client and server-side remote bug.
<!-- SBZ_reproduce --> ...
Created attachment 27592 [details] audit log for racoon ...
Date: Tue, 18 Jan 2005 00:07:42 +0100 From: VANHULLEBUS Yvan <vanhu@free.fr> To: Sebastian Krahmer <krahmer@suse.de> Cc: ipsec-tools-core@lists.sourceforge.net, security-team@suse.de Subject: Re: [Ipsec-tools-core] racoon security flaws On Mon, Jan 17, 2005 at 05:50:04PM +0100, VANHULLEBUS Yvan wrote: Hi again. [Isakmp Header and DOS] > Perhaps we could start by sending a warning about "potential DOS when > logging is enabled" to public MLs. I should never do something else while writing such mail... Of course, this is not so simple, because the DOS also exists without logging.... So we have to warn "everybody" about a potential DOS in all current versions of racoon, including ipsec-tools and including KAME's racoon. > After that, we'll have to quickly fix that, then decide how to > coordinate the release of the fixed version. This still looks to be the main problem, as we will have at least two CVS repositories to update quite the same time, as the fix will probably be enough for a black hat to understand how to generate the DOS. I guess it may be possible to provide the fix to distributors of binary versions of racoon (Linux distributions, etc...) some time before the public source fix, that may be enough for most users to update, without releasing too fast too much informations about the problem. Yvan.
Date: Tue, 8 Feb 2005 13:59:55 +0100 From: VANHULLEBUS Yvan <vanhu@easyconnect.fr> To: Sebastian Krahmer <krahmer@suse.de> Subject: Re: racoon fix On Tue, Feb 08, 2005 at 12:09:03PM +0100, Sebastian Krahmer wrote: > > Hi, Hi. > Are there any news wrt the racon daemon? Not really. I sent a mail to a KAME developper, but didn't have any answer for now. I know how to easily fix the check in parse_woh, but it probably won't be enough. Checking all calculs is quite a long work, and I didn't have time to do it for now. And I send a mail again at ipsec tools core list to remember other members that we still have this problem, but didn't have technical answers. So it looks like we're going to just fix the parse_woh, for most branches, and according to some other team members, at it is "only" a potential DoS which does not seem to be easy to exploit, there will probably be just a commit. But we can delay it a little bit if vendors asks for a private fix first. And to make things more complex, I'll be out for next days... Yvan.
Created attachment 28991 [details] Fix for generic header issue This is a fix from ipsectools project to fix the generic header parsing issue. Not sure how to proceed with the other issues.
Sebastian is not able to access his bugzilla account at the moment. Can you please make updates with the patch we currently have. The part missing will be fixed later.
Date: Fri, 11 Mar 2005 11:50:42 +0100 From: VANHULLEBUS Yvan <vanhu@free.fr> To: vendor-sec@lst.de Cc: Sebastian Krahmer <krahmer@suse.de>, ipsec-tools-core@lists.sourceforge.net Subject: [vendor-sec] Re: racoon remote blub User-Agent: Mutt/1.3.28i X-Spam-Level: Hi. For your information, the racoon patch will be commited to ipsec-tools CVS (at least HEAD, V0.6 and V0.5) on sunday afternoon (GMT), unless someone have a really good reason to ask for a new delay. I suggest all advisories to include something like "you still should NOT enable debbuging (-d) on production systems, as some potential issues are still probably present there". I'll send a public advisory for that to ipsec-tools-devel and merge@kame.net (racoon@kame.net ?) lists this afternoon, which will "only" warn about an imminent commit, and suggest to disable logging on productin systems, but with no more details. There is no CVE assigned / public advisories for that afaik (neither for the kernel fix which has been reported this week), can someone help me coordinate that ? Yvan.
JB: "Use CAN-2005-0398 for the racoon issue."
SWAMP TASK-ID 5060
SM-tracker ID 601
Could you please submit packages, I submitted patchinfos. The fix is attached.
Created attachment 31419 [details] patchinfo for box patchinfo for box
Created attachment 31420 [details] patchinfo for maintained patchinfo for maintained products
Ok, I submited the new packages for sable and sles9; May you find anything I've done wrong, please let me know. (I'm very new to maintaining packages, as mludvig gave this package to me very recently)
I think we also need packages for SL 9.1, 9.2 and 9.3
9.1 = SLES9 9.3 = STABLE so 9.2 was missing.
I submited the package for 9.2 as well, hope it's ok
Fixed packages for all of 9.1, 9.2 and 9.3 were accepted by autobuild (some time ago), closing.
they have vnot been released yet, reopen for tracking
updates released.
CVE-2005-0398: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P)