Re: NISCC's culmination of sitting on an ISAKMP vulnerability for 4 months

[Paul Wouters <paul () xelerance com>]

On Mon, 14 Nov 2005, Dave Aitel wrote:

> I've always wondered why vendors don't all have their own fuzzers. It would
> seem part of a "good development methodology" to have one, right?  I'm sure
> there's something about it in "SCRUM" or "AGILE" whatever the development
> methodology is that most companies use these days.
>
> PROTOS finds some weird stuff, but deep down it's a blind fuzzer. You guys,
> and the Cisco IPSEC team, should be able to write a much better fuzzer - you
> know the protocol inside and out, and, in the case of Cisco, they have a lot
> of money to throw at the problem!

As you can see from the CVS in the last six months, that is exactly what we
have done. See the USE_TAPROOM feature (default disabled). It allows us to
take a packet from the IKE daemon, mutilate it, and put it back into the
IKE daemon for continued processing.

The code is there, but our test harness has not yet been extended to use
this code.

Also note that this was not a buffer overflow or anything. We specifically
test for all assumptions of proper data contents with an assertion. If
we see something unexpected, we abort. So we recognised this malicious
packet as bogus (key length not a multiple of 3 for 3DES). Unfortunately,
it is very hard to properly handle the state machine in these cases. You
cannot just throw the packet away and let the state machine be. Therefor,
we  fail hard and restart the entire IKE daemon. But at least we get
reports of people this way when their IKE daemon crashes (nicely).

> Just a thought. I think it's interesting how throwing a ton of money at
> security DOES work.

Unfortunately, even though massive amounts of fortune500 companies and the
military uses our stuff everywhere, they aren't throwing us that much money.

> And SPIKE and PeachFuzz are free, after all, as long as your corporate
> guidelines don't prohibit you from using GPL software the way MS's does. :>

That would be intriging, since Openswan is GPL :)
I will look into those two packages, thanks for the pointer.

I just wonder if NISCC's existence is actually more harmful then their
non-existence. their plan was to at least wait 7 months on this cross platform
vulnerability, known to affect "a large vendor" (not us, I assume Cisco?)

Paul