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