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.
