RE: SendGate: Sendmail Multiple Vulnerabilities (RaceCondition DoS, Memory Jumps, Integer Overflow)

["Mehta, Neel (ISS Atlanta)" <NMehta () iss net>]

Gadi,
 
Please double-check your work before you make outlandish claims, or perhaps have someone who can read C help you out. 
The details about the memory leak you posted on your blog are completely wrong.
 
Read the comment from Eric Allman:
 
http://blogs.securiteam.com/index.php/archives/365
 
Thanks,
 
-Neel
 
-----Original Message----- 
From:   Dowd, Mark (ISS Atlanta) 
Sent:   Thu 3/23/2006 7:34 PM 
To:     Gadi Evron; dailydave () lists immunitysec com 
Cc:     
Subject:        RE: [Dailydave] SendGate: Sendmail Multiple Vulnerabilities (RaceCondition DoS, Memory Jumps, Integer 
Overflow)

        Hi, 

        The bug i found is remotely exploitable and i have code that proves it, as per the requirements of my job and 
our reporting procedures. Your claim that it's just a DoS incorrect, what would lead you to assume that? Have you even 
researched the bug?

        -mark 


        -----Original Message----- 
        From:   Gadi Evron [mailto:ge () linuxbox org] 
        Sent:   Thu 3/23/2006 4:42 AM 
        To:     dailydave () lists immunitysec com 
        Cc:     
        Subject:        [Dailydave] SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, 
Integer Overflow)

        Tech details: 
        Sendmail vulnerabilities were released yesterday. No real public 
        announcements to speak of to the security community. 

        SecuriTeam released some data: 
        "Improper timeout calculation, usage of memory jumps and integer 
        overflows allow attackers to perfom a race condition DoS on sendmail, and 
        may also execute arbitrary code." 
        More here: http://www.securiteam.com/unixfocus/5RP0L0UI0S.html 

        ISS only reported the Race Condition (DoS?). The Sendmail Advisory 
        reported the Race Condition DoS, the Memory Jumps and a 
        "theoretical" Integer Overflow. 

        To begin with, anyone noticed the memory leak they (Sendmail) silently 
        patched? 
        I wonder how many other unreported silently-patched 
        vulnerabilities are out there? 

        Second, the Integer Overflow is practical, not theoretical. 

        ISS reported the Race Condition last mounth. There is NO data available on 
        when the other vulnerabilities were discovered. Any guesses? 

        They also patched many non-security related bugs, added checks and more 
        informative error messages, etc. 

        Sendmail is, as we know, the most used daemon for SMTP in the world. This 
        is an International Infrastructure vulnerability and should have been 
        treated that way. It wasn't. It was handled not only poorly, but 
        irresponsibly. 

        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. 

        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). 
        They changed the logic of the code, replaced everything that calculated 
        timeout. Anything that calculated something and returned a value now 
        returns a boolean result, when previously they just returned void. They 
        used to look at the content rather than success. 

        The int overflow is possibly exploitable, not very sure about the 
        jumps. No idea why ISS says the Race Condition is, would love insight. 

        Public announcement 
        ------------------- 
        FreeBSD were the only ones who released a public announcement of a patch 
        and emailed it to bugtraq so far. 

        The patches 
        ----------- 
        The FreeBSD patch much like the sendmail.org patch is very long, 
        complicated and obscure. The release was made along with a ton of other 
        patches for FreeBSD. Go figure what's in there. 

        Sendmail.com's patch is so big they may as well have re-released the whole 
        program. 

        There are also patches available for other *nix systems, no distributions 
        released updates yet. 

        Sendmail's announcement 
        ----------------------- 
        Obscure. Not worth any other comments other than the ones above. 

        CVE information 
        --------------- 
        CVE-2006-0058 (reserved) 

        Commentary 
        ---------- 
        One could say ISS and Sendmail did good, obscuring the information so that 
        the vulnerability-to-exploit time will be longer. That proved wrong, 
        useless and pointless. They failed. 

        After looking at the available data for 30 minutes (more or less), we know 
        exactly what the vulnerabilities are. Exploiting them may not be that 
        trivial if indeed possible,  but there are most likely already exploits 
        out there if it is. When will the first public POC be released? Your guess 
        is as good as mine. 
        Not to mention the silently patched memory leak. 

        SMTP and Sendmail by extension are critical for the Internet as an 
        International Infrastructure. If this ends up being exploitable (no 
        details, remember?) both ISS and Sendmail should look good and hard at the 
        coming massive exploitation of Sendmail servers. 

        With issues relating to the Internet Infrastructure I'd be willing to go 
        even with the evil of non-disclosure, as long as something gets done and 
        then reported publically when it finally scaled down in a roll-back after 
        a couple of years. 
        If not, and you are going to make it public, make the effort and fix it as 
        soon as you can, and give information to help the process of 
        healing. Don't do it a mounth late and obscure data. 

        It took Sendmail a mounth to fix this. A mounth. 

        A mounth! 

        With such Vendor Responsibility, perhaps it is indeed a Good Thing to go 
        Full Disclosure. It seems like history is repeating itself and Full 
        Disclosure is once again not only a choice, but necessary to make vendors 
        become responsible. 

        I wish we could somehow avoid all the guys who will inevitably shout in 
        the press "end of the world". The Internet is, was and will stay 
        havoc. There will be exploitation. Those who care about security will be 
        patched, those that don't will hopefully finally learn a lesson. The 
        Internet won't die because of this, although email may suffer ? but we are 
        used to that by now, even when losing money. 

        I am so very angry the details are obscure and hidden in the way they are, 
        especially as that is useless in this case. Why did they do it, to claim 
        they are ?responsible?? Too late. 

        "The avalanche has already started. It is too late for the pebbles to 
        vote." - Kosh, Babylon 5. 

        How are they to show open source is reliable if this is how they act? They 
        hurt the cause. If they don't know how to handle something like this, they 
        should ask for help. 

        What, if it's not reported to Microsoft, there is no reason to be 
        ?responsible?? 

        It's like annoying "fake porn" on TV. Either show the nudity and rate the 
        program accordingly or stay suitable for normal viewing. There is no 
        eating the cake and leaving it whole. 

        "Hey mom, what's my root password? I forgot" 
        "Dunno, just use the new sendmail vulnerability!" 

        They should learn from Apache. With such a critical vulnerability I know 
        the Apache guys would not have slept until it is patched! 

        We will update on the situation if required on http://blogs.securiteam.com 

        This text can be found 
        here: http://blogs.securiteam.com/index.php/archives/363 

                Gadi Evron.