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: <42D9AED3.5070406@kc.rr.com>
Date: Sun Jul 17 02:05:50 2005
From: mattmurphy at kc.rr.com (Matthew Murphy)
Subject: Compromising pictures of Microsoft Internet
	Explorer!

tuytumadre@....net wrote:

> I do not meen to flame you, but you are an irresponsible disgrace to 
> the hacking community. Do you not care about the customer? You never 
> publicly disclose details to a vulnerability of this magnitude. This 
> is an image vulnerability, for crying out loud.
>
Sure you do.  You disclose the details of the vulnerability when the 
vendor has a proven history of non-responsiveness, and the damage that 
the vendor is able to do by stalling the release is most likely greater 
than the damage that will result from disclosure of several non-critical 
flaws.  AFAICT, IE 6.0 SV1 merely crashes when faced with these issues.  
According to Microsoft, it's not a vulnerability at all unless there's 
an attack vector enabling code execution.

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.

> What's the first thing they tell you to do when most vulnerability 
> details are released? Disable active scripting. That doesn't work 
> here. What are the innocent, ignorant computer users going to do? 
> Disable images? I think not. You should be ashamed.
>
The point you miss, is that thanks to Mr. Zalewski's decision to publish 
the details of this vulnerability ensures that AV/IDS signatures exist 
for the portion of users who care to update them.  Meanwhile, I can 
afford to wait the six, twelve, eighteen, or twenty four months that 
Redmond takes to patch IE issues.  Or, maybe it will be a refreshingly 
reduced timeline, only a month or two, since this is a supposedly 
critical issue.

>  
> I firmly believe that you are decieving us when you say you had a hard 
> time with secure@...rosoft.com <mailto:secure@...rosoft.com>; in fact, 
> I don't even think that you have ever once in your life reported a 
> vulnerability to them responsibly. Otherwise, you would not have such 
> harsh feelings about them. If the evil of the stereotypical Microsoft 
> machine exists anywhere on the campus in Redmond, it will not be found 
> in the building of MSRC, which is where your secure@...rosoft.com 
> <mailto:secure@...rosoft.com> emails are directed.
>
...and I firmly believe that you have never had the experience of 
attempting to triage a vulnerability that was anything less than 
critical through Microsoft.  If you have, as I have, you'll understand, 
as I do, that it's possibly the closest thing to hell you'll go through 
in your research work.  The "evil of the stereotypical Microsoft 
machine" isn't as much an evil as an ineptitude.  Microsoft's current 
processes have huge problems with efficiency, quality, and effectiveness 
that have few parallels in the industry, and it isn't for lack of 
resources.  And aside from that, they require the researcher to provide 
a full, complete assessment of impact.  That's not feasible for a great 
number of us, who are, after all, nothing more than volunteers.

I'm a college student with a laptop and a few reverse engineering 
tools.  If an issue is discovered that appears to permit some degree of 
compromise of a customer's PC, I _should_ be able to count on the MSRC 
to investigate the issue sufficiently to prove that damage is 
sufficiently unlikely/impossible.  Instead, the inverse is true, with 
MSRC counting on me (the volunteer) to do the hours of research to prove 
that a vulnerability exists.  And if the impact is anything less than 
remote code execution, prepare for at best a lengthy debate, at worst 
your report being swept under the rug with a maintenance release that 
never actually happens.

The response (in a few less words) that many researchers have to these 
conditions is "F--- it!".  And, in my experience, it's certainly 
justified.  Why am I volunteering my time to one of the world's largest 
corporations, when they don't care enough about their customers to give 
fairly obvious security issues their due diligence?  After all, I don't 
have their code.

Particularly given Redmond's tendency to take eternities to solve bugs 
that are "responsibly disclosed" to it, I'm thankful that the action was 
taken as it was, and not as you wish, for my "safety and protection".  
If nothing else, Michal's report is further confirmation that Internet 
Explorer is one of the modern world's greatest programming disasters, 
and should be avoided at all costs, if you are a sysadmin intent on 
keeping your systems safe.

> Come on man. I know you have talent. You are a good researcher of 
> computer security. But if your talent is going to be wasted like this, 
> you are nothing more to us than a script kiddie.
>
Sorry, but you have about as much claim to speak for "us" as this e-mail 
speaks for you.  Now, at least my AV/IPS systems can attempt to block 
this attack.  Sure beats sitting waiting, uninformed, while Redmond 
deliberates over its delivery mechanism and release schedule.  Also, 
vulnerability information such as this has helped me make another 
important decision: to quit using IE altogether.  Until Internet 
Explorer's code undergoes a significant paradigm shift from a system 
component back to its proper place in network design as a user 
application, and until Microsoft's security processes undergo 
significant reform in the areas of quality, rapid response, and 
researcher-developer collaboration, issues like this will keep coming up.

And, if Michal was so wrong, we should soon be asking ourselves the 
question... where's the patch?  After all, if Microsoft doesn't witness 
active exploitation of the issue, the soonest patch we can hope for is 
in the monthly cycle; that seems to be crucial in the effort to prevent 
Redmond's patches from turning systems into electrically-powered boat 
anchors.

"Responsible disclosure" is only responsible if both sides act in that 
fashion.  Microsoft seems to rarely do so unless faced with a 
significant peril if it does otherwise.  As such, a decision by Michal 
to report the issue privately to Redmond, while it takes its sweet time, 
seems equally irresponsible.

I'm a firm believer in responsible handling of vulnerability 
information.  But I'm also a firm believer in holding people accountable 
for their mistakes.  Mistakes happen, but vendors have an obligation to 
correct them.  Microsoft has not corrected the fundamental failures of 
its issue handling processes to date (as my recent experiences show), 
and as such, I feel that there is no obligation (moral, ethical, 
professional, or otherwise) to them on anyone's part.

Regards,
Matthew Murphy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2789 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050716/30c672dc/smime.bin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ