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