Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
On Thu, Mar 23, 2006, Gadi Evron wrote:
> To begin with, anyone noticed the memory leak they (Sendmail) silently
> patched?
Hmm, which one? Please read the code carefully and tell me where
the leak is (was).
> Second, the Integer Overflow is practical, not theoretical.
It is avoided by the standard configuration.
> They say it's a remote code execution. They say it's a race condition. No
> real data available to speak of. I can't see how it's remotely
> exploitable, but well, no details, remember? From what we can see it seems
Ask ISS about the exploit. It definitely is a programming bug,
just read the man page for setjmp() on an OpenBSD system.
> What they did behind the smoke-screen is replace a lot of setjmp() and
Which "smoke-screen"?
> longjmp() functions (not very secure ones at that) with goto's
> (interesting choice).
What's interesting about that?
if (function-call == failed) goto error-handler;
seems like a common way to deal with "fatal" errors (and an I/O
error in an SMTP server means you have to abort the connection).
How do you deal with errors?
> The int overflow is possibly exploitable, not very sure about the
First you have to turn off the default limit.
> jumps. No idea why ISS says the Race Condition is, would love insight.
Ask ISS.
> Sendmail's announcement
> -----------------------
> Obscure. Not worth any other comments other than the ones above.
What's obscure about http://www.sendmail.org/8.13.6.html ?
> Not to mention the silently patched memory leak.
Please check your facts.
> It took Sendmail a mounth to fix this. A mounth.
No. It took sendmail a week to fix this. The rest of the time was
used to coordinate the release with all the involved vendors etc.
Can you do me a favor? Next time you want to spread information
about a "memory leak" or something similar: contact the author(s)
first. See sendmail.org's website.
PS: I don't speak for anyone but me.