Message-ID: <200603240912.k2O9Cokp040098@mailserver3.hushmail.com>
Date: Fri Mar 24 09:13:05 2006
From: 0x80 at hush.ai (0x80@...h.ai)
Subject: Re: SendGate: Sendmail Multiple Vulnerabilities
	(Race Condition DoS, Memory Jumps, Integer Overflow)

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

Do you live under a rock? There were a lot of public announcements 
about this.

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

Yes.  There was a presentation at Blackhat Europe about this.  It 
happens all the time.  Vendors do not practice responsible 
disclosure but they expect you to.

> 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.

So in one sentence you say that the ISS bug is only a DoS and now 
you are crying that a bug is being handled irresponsibly?  Don't 
you have already talked to death DNS attacks to sound the alarm 
about?

> 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.

So if in the best of your abilities this is only a DoS ---> why cry 

over so called irresponsible disclosure of a bug?  Oh wait, the 
minor memory leak that you think you found is the issue.

> 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).

So what would you have done?  What smoke-screen are you talking 
about?

> The int overflow is possibly exploitable, not very sure about the 


> jumps. No idea why ISS says the Race Condition is, would love 
> insight.

You got that right.  We would all love you to get some insight.

> 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.

Obviously.  I mean if *you* couldn't figure out how to exploit the 
ISS issue then they must have failed.  Or wait, you couldn't figure 

it out so perhaps they failed but are still smarter than you.

> After looking at the available data for 30 minutes (more or 
less), 
> we know exactly what the vulnerabilities are. Exploiting them may 



So after 30 minutes you were wrong about an issue.  Tell me again 
how smart you are.

>Not to mention the silently patched memory leak.

Alert the press.  DNS is can be attacked AND there is a memory leak 

in Sendmail.

> both ISS and Sendmail should look good and hard at the coming 
> massive exploitation of Sendmail servers.

Nah the 1337 h4x0rs will be too busy going after DNS right?

> 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.

Yeah, that will work.  Because, no offense Mark Dowd, no one else 
could have found the problem.  Well at least we know that the world 

is safe from you.

> 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.

So if you find a bug, it should be fixed and released on the same 
day you find it.  Yeah right.

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

A whole month?  The horror!  Babies will die and our women will 
raped if vendors continue to take an entire month to address as 
many issues addressed in the Sendmail patch.

> A mounth!

Mounth?  So first you say no details should have been released for 
at least 2 years and now you are crying because it took a month to 
come up with a patch.  Do you even read the shit that seems to flow 

from your brain to your keyboard?

> 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.

WTF are you talking about?  The bug has been disclosed.  The patch 
released.  Why are you complaining?  How was Sendmail irresponsible 

by fixing an issue and releasing a patch?  I think you have lost 
your meds.

> 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 

Except for you right?  Answer your phone.  Its the kettle calling.  

Speaking of pot perhaps you should smoke less before sending emails 

to lists.  Have you not shouted about DNS have you not shouted in 
this tripe filled email about how irresponsible Sendmail and ISS 
are because the issue is so dangerous and that Sendmail and ISS 
should watch the mass exploitation that their evil ways will cause?

One could hope that someone will take away your ability to send 
email and post to lame websites but we are not that lucky.

> 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.

Grrrrr.  I am so very angry that you cannot form one sentence 
without contradicting yourself.  Grrrrr

> 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.

Open source is no more reliable than anything else.  I think it is 
safe to assume that both Sendmail and ISS have a lot of experience 
in dealing with security issues.

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

?
> responsible??

How is working with a vendor to get a patch released not 
responsble?  How is getting a fix into a package in 30 days not 
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.

Perhaps you should spend more time jerking to porn and less time 
worrying about things you obviously do not understand.  Just a 
suggestion.

> They should learn from Apache. With such a critical vulnerability 

I 
> know the Apache guys would not have slept until it is patched!

So are you saying Apache has never taken more than 30 days to patch 

an issue?

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

I am sure the readers of this and every other mailing list you are 
going to post this crap to will be sitting on the end of their 
seats awaiting your next insightful, intelligent, and as always 
100% correct post.




Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485

Powered by blists - more mailing lists