SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
jeroen at unfix.org
Sat Mar 25 16:01:48 UTC 2006
On Sat, 2006-03-25 at 13:30 +0100, JP Velders wrote:
> > This isn't about processes, it's about something that has been around for
> > a while, many reply on and keeps ******* up. Where it simply can't.
> What world do you live in were everything is done perfect ? If you
> don't like sendmail because of its history or that it can contains
> flaws, vote with your feet and choose something that you do think can
> be trusted to do a better job, is more secure, is more actively
> developed and is developed more securely then sendmail. [*]
Indeed, and it is is not like there are no alternatives and of course
one can always roll it's own ;)
And one even didn't have to pay for it, but complaining, and not helping
out by providing patches or research is always the easy way out.
/me chose postfix btw, but mostly also because the config is much
simpler ;) Rolling my own would also be an option, the ones out there
work fine already and so what that they have bugs, no way that one can
code bugfree, just make sure that you can upgrade in time.
> Heck, if I were to have kids one day and would like them to get to
> school safely by car, I'd like to have something short of a tank to be
> absolutely certain. Instead I'll probably make them aware of the
> risks, give them good protection and bicyle helmets... Now if I were a
> head of state or something, I'd probably have people to get me that
> tank... Note the "have people"...
I guess you mean something like a 400.000 EUR tractor (vendor-C term):
The thing is, that might help for the collision case or a small bomb,
but one can still walk up to the guy when he gets out and shoot him
directly in the head or try to cut it off as has been demonstrated twice
before in that country. Bit futile thus to protect yourself with such
spendings when it doesn't cover the obvious cases.
Analogous, starting over using a new product might introduce other
security risks and of course never forget the migration path which in
larger installs includes training and upgrades, problem shooting and
then finding out that new bugs exist in the new code. Even the folks who
moved over from SSH.com to OpenSSH have found out that they had to
upgrade a large number of times, some times even with very troublesome
vulnerabilities, in the end causing most people to rate-limit port 22 or
to move it to another port altogether because of the automated scanning
(Fortunately it was not my tax money that bought that tractor :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 315 bytes
Desc: This is a digitally signed message part
More information about the NANOG