North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Maformed SNMP Packet log/trace

  • From: Richard A Steenbergen
  • Date: Tue Feb 26 19:15:32 2002

On Tue, Feb 26, 2002 at 06:41:22PM -0500, Sean Donelan wrote:
> On 26 Feb 2002, Eric Brandwine wrote:
> > Go to the Oulu University page mentioned in the advisory.
> >
> > Download the 4 .jar files that comprise the toolkit.
> >
> > unzip the jar files.  There'll be a testcases/ dir in each of them.
> > Each file in this directory is one of their packets.
> >
> > There are 53,000 of them.  Have fun!
> And to keep things exciting, programmers rarely make mistakes in
> only one protocol.  Turing still holds.  It wouldn't be surprising
> if other packets can do bad things when "this should never happen"
> happens.  Who is checking NTP, OSPF, ISIS, BGP, SSH, DNS, TELNET,
> TACACS+, etc code paths?

A lot of those protocols have people looking at them on a regular basis,
and they still manage to come up with obscure exploits noone else noticed
(ex: 23mb of buffer overflows to exploit telnetd).

On the other hand, a lot of those protocols (and more specifically their
implementations in routers) have probably never seen the light of day, and
are so rotten we are all better off keeping them covered up. I'm certain 
that more then enough people here can attest to the fact that it doesn't 
take much in the way of "unexpected packets" before certain vendors BGP 
implementations start wigging.

Of course, it is up to the user to decide if they would rather have a
product with 50,000 holes that script kiddies don't know about, or a
product with 100 holes that the do. Most days security through obscurity 
works just fine, but the days that it doesn't really suck.

But SNMP is special. It has the distinct honor of being one of those
protocols which has daylight all around it and yet somehow manages to stay
under a rock. I attribute this to what I like to call the "Upchuck Code
Barrier", namely that very few people have the intestinal fortitude to
look at the existing implementations without hurling their lunch. This
severely limits the number of exploits which are written. :)


Richard A Steenbergen <[email protected]>
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)