Message-ID: <42E5D118.6020701@ddplus.net>
Date: Tue Jul 26 06:59:48 2005
From: dinis at ddplus.net (Dinis Cruz)
Subject: (as apllied to Full Trust Asp.Net vulnerabilities) Re:
	
	Compromising pictures of Microsoft Internet	Explorer!

I also had similar experiences with dealing with MSRC (Microsoft 
Security Response Center) where they were quite pedantic and wanted me 
to send them very detailed information about the issues that I was 
talking about

Eventually I realized that it was not that they were not understanding 
what I was saying, it was that they wanted to know how much I (me, 
Dinis) understood about the issue and how to exploit the vulnerabilities.

And in my case it was worse, because we were arguing about the 
'definition of a vulnerability' where I was telling them that a 
malicious Full Trust Asp.Net script could take over an entire server 
(even following Microsoft's recommended security best-practices) and 
they where saying that THAT is not a vulnerability since what I was 
exploiting was 'built-in' functionality in the .Net framework to attack 
the server.

Their answer to all issues I mentioned (for example: all 
usernames/passwords stored in the metabase can be decrypted by any 
member belonging to the IIS_WPG, the reuse/hijack of the Security Tokens 
that exist in a  IIS Process, the upload and execution of 
binaries/exploits to the server, the fact that most published 
security-advisories also apply to Full Trust Asp.Net/IIS environments, 
the asp.net temporary folders, the default access to WMI, the fact the 
IIS 6.0 doesn't scale very well when multiple Applications pools are 
used,  etc...) is: "that occurs by design in Full Trust Asp.Net"

Eventually I gave up, and since most of the people who should care (for 
example ISPs, software developers, end-clients) don't care (or are not 
aware), I decided that the best use of my time and effort would be to 
write tools that help responsible and security-conscious administrators 
to identify vulnerabilities in their hosting environments. This is what 
I did at Owasp (Open Web Application Security Project) where you will 
find several tools that I wrote: ANSA (Asp.Net Security Analyzer), 
SAM'SHE (Security Analyzer for Microsoft's Shared Hosting Environments) 
, Asp.Net Reflector, Online Metabase Explorer, etc... (The main Owasp 
website is at www.owasp.org and the dotnet section is at www.owasp.net.)

Note that I have been warning Microsoft about these issues for more that 
18months now, and finally it seems to exist some interest in 
acknowledging them (I had a meeting last week in Redmond where we 
discussed this) and at least now (July 2005) they seem to want to do 
something about it (the first step will be to acknowledge the problem).

Although I believe that some care must be placed in the disclosure of 
0-day style vulnerabilities that can be maliciously exploited by worms 
and virus, I don't believe that we should subscribe to the COTS 
'responsible vulnerability disclosure' ideas since they are designed to 
minimize the impact of the vulnerabilities in their stock price, instead 
of increasing the security of their products and clients.

In fact, I have to say that Microsoft for all its sins, it is not the 
worse one in this aspect. At least Microsoft will do the right thing 
when shown a vulnerability which can be maliciously exploited in a 
massive scale. I have had several past experiences where I was working 
for Client X, testing Product Y, and after delivering my report 
(containing several critical vulnerabilities on Product Y) only Client X 
received a patch (because the other clients that used this product were 
not aware of these vulnerabilities, they never complained, where never 
told about this issues and only received the patch in the next 'service 
pack').

And as the low-hanging fruit vulnerabilities dry up, and more time is 
required to find existing vulnerabilities, it is very important that we 
have clear, honest and object discussions about vulnerability disclosure.

But, since this discussion is not possible today (there is too much 
'emotion in the air' :) ), and Full (or almost Full) disclosure of 
vulnerabilities is not always possible (for example when vulnerabilities 
are discovered under NDAs) I think that the best solution is for 
companies to be forced (maybe by government legislation or by client 
pressure)  to disclose how many vulnerabilities in their 
products/websites their are aware of (either found internally  
communicated to them by a client or security research company). This 
could be a bit like what eEye does these days when they say that a 
vulnerability has been discovered, when it was discovered/communicated 
to the vendor, talk about the it impact, but don't publish technical 
details about it until a patch is released.

Dinis Cruz
.Net Security Consultant
Owasp .Net Project Leader


Bernhard Mueller wrote:

>>Mr. Zalewski's statement about the undue burden that Microsoft's
>>investigative processes place on the researcher is indeed accurate.  The
>>only time I've had any success working with Microsoft was when the issue
>>was a straightforward code execution scenario.  Oh wait... even then,
>>I'm blown off.
>>    
>>
>
>the same here... when I mailed them about that COM-vulnerability in IE,
>they came up with "this is not exploitable, bla.." after two weeks of
>internal research
>and all. having a bad morning anyway, I decided to post the advisory and
>see, one day later there's a MS security advisory that "a COM object may
>crash internet explorer" (however, they forgot to mention the public
>bindshell exploit released by the fsirt).
>now recently MS05-37 came out, which somehow doesn't include any credits
>  or mention of the original advisory whatsoever (the reason for that
>being, i presume, the lack of responsibility showed by us).
>I think it's rather strange to hear a billion-dollar software monopolist
>apply to my conscience like "look what you've done, you put our
>customers at risk". they wouldn't give a lame cent on the security of
>their customers if there wasn't a certain media hype about security.
>they care for their image and stock index, and that's about it. and i
>don't see why should be held responsible for that ;)
>
>
>regards,
>
>sk0L
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050726/aed895f3/attachment.html

Powered by blists - more mailing lists