SendGate (Sendmail vulnerabilities data)

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!

special thanks go to ido kanner for all his help.

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,
ge@beyondsecurity.com.

Share
  • Pingback: SecuriTeam Blogs » SendGate (Sendmail vulnerabilities data)

  • Pingback: SecuriTeam Blogs » trusting SMTP (more on SenderGate: SMTP Multiple Vulnerabilities)

  • Pingback: DivisionByZero WebLog»Blog Archive » kwetsbaarheid in sendmail

  • Foo

    A mounth!!!!!

  • http://www.cs.tau.ac.il/~adamx/ Adam Morrison

    Welcome to the other side of “closed” and “vetted” disclosure.

  • http://thc.org rd

    sunshine, your post contains too much of misunderstood things. there’s no silent mem leak patch and the bug iss found is exploitable (u would need to use some tricks;). regarding the lack of detail in advisory, iss (and others such as ngs, eeye, ..) nowadays used to not post the detail information in thier advisory. but you can always find the detail somewhere else or find it yourself by looking at the patch.

  • sunshine

    Hi rd, how are you?
    I was saying I personally couldn’t see how it got done and asked for details and to be “enlightened”. Indeed, I tend to believe the ISS guys.

    As to disclosure, this situation is different.

    Sendmail is critical infrastructure for the Internet. One can either go full disclosure of non-disclosure, you can’t do both, as you will fail. They did.

  • j

    Boy, that’s a “mounthful.” Easy to understnad when someone’s been eating too much cake. ;)

  • Trial

    sunshine, you are a complete media whore. it’s so painfully obvious that all you are interested in is a bit of media coverage.

    you do not have the technical ability to analyse this vulnerability or the accompanying patch in any meaningful way. apparantly nor does anyone else at securiteam. there is no scandal here that warrants a comparison to watergate. you do not know how to write. iss and sendmail have not been proved wrong in any way (i really hope you weren’t trying to imply that your “analysis” was proof). you seriously misunderstand the purpose and mechanism of full-disclosure. and you seriously overestimate your importance.

    i honestly don’t know how you can put your name on these mindless ramblings. if you are not feeling embarassed about this, take heart in the fact that many others are embarassed for you. you are a joke.

  • http://networksecurity.typepad.com/ Juha-Matti Laurio

    SecurityFocus has their BID17207 Sendmail advisory but it seems that the title is ‘Retired: Sendmail SM_SysLog Remote Memory Leak Denial Of Service Vulnerability’ now:

    http://www.securityfocus.com/bid/17207/discuss

  • Pingback: SecuriTeam Blogs » Code Red: Opera Cannot Handle Insufficent Disk Space and the SecuriTeam vs. Sendmail armed conflict

  • anon

    TV porn? What the hell are you blabbering on about? The whole ‘article’ is just pointless superficial rambling. You doesn’t explain anything, merely spout out a bunch of cliches about open vs closed source .. and cliches should be avoided like the plague.

  • http://www.sharetab.com Saurabh

    Thanks for the informative note.