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.
