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