bugtraq - Re: 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: <200603231213.23249.dr@kyx.net>
Date: Thu, 23 Mar 2006 12:13:23 -0800
From: Dragos Ruiu <dr@....net>
To: Gadi Evron <ge@...uxbox.org>, bugtraq@...urityfocus.com
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: SendGate: Sendmail Multiple Vulnerabilities
	(Race Condition DoS, Memory Jumps, Integer Overflow)

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.

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.

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.

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

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/