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

Dragos Ruiu dr at
Fri Mar 24 05:32:26 UTC 2006

On March 23, 2006 06:08 pm, Steven M. Bellovin wrote:
> On Thu, 23 Mar 2006 03:41:52 -0600 (CST), Gadi Evron <ge at>
> wrote:
> > It took Sendmail a mounth to fix this. A mounth.
> >
> > A mounth!
> Given the scope of the changes you describe -- you wrote "'s
> patch is so big they may as well have re-released the whole program."
> -- I can't get upset at taking a month to fix it.  You're dealing with
> asynchronous events, which are really hard to start with.  I suspect
> that they spent some time deciding how to fix it -- you don't appear
> thrilled with their choice, but I don't know what other options they
> considered -- and then actually tested the new code.  Given how many of
> our security problems are due to buggy and inadequately-tested code, I
> suspect that taking a month was actually being quite responsible.

Hey I'm the first guy to line up to knock Sendmail a.k.a. the pit of
infinite flaws... but lets not beat people up who don't deserve it.

My understanding of it was they found out from ISS and fixed it 
ASAP. (I'm sure they read this list, maybe they would care to comment)
They took two weeks to update their customers and released it to CERT
who was supposed to take two weeks - starting three days ago... but something
happened (as it always does :) and it was sent out prematurely - widely.

Hence again some people got caught off guard.
I'm increasingly forming the opinion that waiting for patches on disclosure
actually does harm. (Though I conceed that this is a religious issue
likely never to be resolved.)

Responsible disclosure may in fact be immediate disclosure so 
that people can measure impact without waiting for the inevitable 
vague wordings. That way we can take any countermeasures possible 
immediately - rather than being vulnerable in the silence while 
"special" people know. Resulting in not doing anything or being 
increasingly watchful as would be warranted. If you know your 
mailserver is vulnerable but you can't fix it you can always 
start to watch it like a hawk - if you know.

I guess it depends on your security posture. If you are agressive 
on security you want information dispersed as widely as possible.
If you are putting in minimal effort, then the less people know 
the better it is for you.

Though only time will tell, I would also bet that this is not the last 
sendmail signal handler issue we will see... at least until the more 
Postfix-like commercial-only next version comes out... and then we 
will have a brand new code base full of untested code to deal with.
And since its taken a few decades to stabilize Sendmail up to
_this_ point.... I'll just hug my Postfix code and resolve to buy
Mr. Venema beer at the first available opportunity :).


P.s. I still maintain that the right solution is to convince IBM to tweak
the Postfix license so those who absolutely need fully open source 
can use it instead. I've personally audited a lot of that code and know
how incredibly robust, nee paranoid it is. :-). Because when Sendmail
X comes out the open source folks will have a big issue to deal with.

World Security Pros. Cutting Edge Training, Tools, and Techniques
Vancouver, Canada    April 3-7 2006
pgpkey kyxpgp

More information about the NANOG mailing list