SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)

Valdis.Kletnieks at vt.edu Valdis.Kletnieks at vt.edu
Sun Mar 26 02:04:30 UTC 2006


On Sat, 25 Mar 2006 00:57:31 EST, "Steven M. Bellovin" said:
> On Sat, 25 Mar 2006 04:39:11 +0200, Gadi Evron <ge at linuxbox.org> wrote:
> 
> > 
> > Valdis.Kletnieks at vt.edu wrote:
> > > Well, it *is* mostly a theoretical overflow - for it to work, a site woul
d have to:
> > 
> > Exploit is out there. How long did that take?
> > 
> Is the exploit actually effective in the wild?  The conditions Valdis
> spoke of are improbable -- are there actually vulnerable sites?  Or is
> the attack much easier than he had indicated?

The race condition is easily winnable in the wild.

The integer overflow is essentially unexploitable in the wild, as it involves
*two* buffers, one of which is a compile-time constant bigger than the other.

The compile time constant is 1024 by default.

To trigger the overflow, the first buffer has to be *under* 2G (2**31) in size,
and the second is (by default) 1024 bigger and *over* 2**31 in size.  At this point,
the attacker has sent 2 gigabytes of data over the wire, and the victim has
grown a buffer by 1024 bytes, copied, grown, copied, grown, copied, a total of
2,097,152 or so times.  Oh, and you need to fit those almost 2G buffers,
*plus* 500K or so of Sendmail binary, in 1 4 gigabyte address space.  That's
if you're on a 32-bit machine.

Oh dear, you seem to be about 497K short.  At least.

I suppose some idiot site *could* have recompiled their sendmail to allocate
in 8 megabyte chunks rather than 1K.  But performance would suck eggs.

Oh, and on a 64-bit machine, it's not any better.  You *still* have to fit
2 buffers plus the 500K in under the 2**64 line.  And you need to send
that much data too.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20060325/94a29988/attachment.sig>


More information about the NANOG mailing list