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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.21.0603241141290.31564-100000@linuxbox.org>
Date: Fri Mar 24 19:21:11 2006
From: ge at linuxbox.org (Gadi Evron)
Subject: SendGate: Sendmail Multiple Vulnerabilities
	(Race Condition DoS, Memory Jumps, Integer Overflow)

On Thu, 23 Mar 2006, Dragos Ruiu wrote:
> On March 23, 2006 01:41 am, Gadi Evron wrote:
> > Here's what ISS releasing the Race Condition vulnerability has to say:
> > http://xforce.iss.net/xforce/alerts/id/216
> > 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
> > like a DoS.
> 
> ISS's Mark Dowd is very clever guy. And if duke says it's exploitable
> I would believe him :-).  It's an interesting new vector anyway.

Indeed, which is why I said I can't see how and asked for details, as well
as in the next paragraoph that I would be happy to be enlightened.
:)


> But like all timing related attacks, the question is reliability.
> Though gossip has it, this one is repeatable with sub-100 attempts
> and you get infinite shots at it because even if the process 
> does die it's a child of the parent listener. (So it is not really
> a DoS per se in any case.)
> 
> >
> > Bottom line
> > -----------
> > What they did behind the smoke-screen is replace a lot of setjmp() and
> > longjmp() functions (not very secure ones at that) with goto's
> > (interesting choice).
> 
> Smoke screen seems like unfarily loaded terminology to use.
> 
> OpenBSD fixed (removed) many setjmp/longjmp functions in their
> tree a long time ago as a class of bugs. (Though this sendmail 
> exploitable collecttimeout() longjmp one is new and they patched
> it yesterday with everyone else, because as you noted, replacing
> it was kinda hairy...)
> 
> I don't think its fair to bitch about people fixing bugs and then not
> having the time to send out advisories for every little tweak.
> The important thing is to fix the bug. And often times the 
> developer won't understand the real impact of fixing a bug 
> until someone clever like Mark comes up with some innovative
> way to exploit an "unexploitable" bug like this one.

I would tend to agree, however, sendmail have been very irresponsible in
the past, and with all due respect, if they want to play at being critical
internet infrastructure, they should live up to expectations or find a new
game.

> 
> What will be interesting to see when the PoC exploits are 
> finally released, is if any of the memory/stack protection schemes
> mitigate it.
> 
> <humor>
> Besides, there is only one true mailer to mail them all,
> and its name is Postfix.
> </humor>

:)

> Now if we could only convince Mr. Venema to switch 
> to a BSD license _everyone_ would switch to Postfix
> and everything would be much better. If it weren't for
> that "poison pill" clause in its license, I'm sure most
> OSes and commercial systems would have swapped 
> out Sendmail for Postfix long ago.

I agree, Postfix is incredibly good.. once you learn to get along with it!

> 
> cheers,
> --dr
> 
> -- 
> World Security Pros. Cutting Edge Training, Tools, and Techniques
> Vancouver, Canada    April 3-7 2006     http://cansecwest.com
> pgpkey http://dragos.com/ kyxpgp
>