-
Website
http://www.matasano.com/log -
Original page
http://www.matasano.com/log/851/mcafee-for-us-its-internet-first-then-customers-unlike-3com/ -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
The good folks at McAfee need to get their facts straight.
the world doesn't need more attack code... proving exploitability doesn't require attack code (better to use benign exploit code rather than fully functional attack code)... the anti-virus industry tries it's best not to provide incentives for producing attack code as it creates an ethical conflict with their implicit goal of fighting such code...
I'm actually going to assume that the blog post was not the offical opinion of McAfee, but rather made by some over eager vuln researcher who didn't take time to do his homework.
It is hard to dignify a response to the blog posting by McAfee, as it's full of the same self-proclaimed FUD that their author is out to denounce; however the facts represented by them are just plain wrong. In order to set the record straight yet again, for reference:
ZDI advisory is here with timeline of disclosure events (vuln disclosed 30 minutes to Apple after officially buying it from Dino).
ZDI disclosure policy here.
Final thoughts and rebuttals on the hacking contest in our blog posting here.
In order to help protect a larger customer base than our own, we also share ZDI information free of charge to any IPS competitor that asks for it, with minimal fine print and an iron clad NDA.
If I crash something... that's a DoS... If I report that to the vendor, they'll ignore it and say "We'll fix it in our next service pack". However, if I produce remote code execution and give that to the vendor, they'll patch it more quickly because they realize the risk...
The fact that vendors operate that way is why we need people finding vulnerabilities and producing exploits...
Having something like ZDI only benefits the security industry... providing incentive for responsible disclosure... It's 100% benefit to the security industry.
It sounds more to me like the AV industry would rather ignore the problems, or wait until the bad guys find them first... I guess that's the problem.. AV will always be a reactive counter measure... Tipping Point/ZDI is spending money to make their IDS/IPS even more proactive. To me this is more of a case of sour grapes... People are envious of the actions being taken by Tipping Point... They are taking that extra step to protect their customers... The AV companies would rather sit back and wait for the virus/worm/trojan that exploits a vulnerability then proactively find the vulnerability before the bad guys so that the vendor can properly patch it.
As a consolation, virus scanner writers will always have a job. Computer security practitioners will only be employed as long as people are writing new buggy software and patches and old bugs go unfound! (Don't quit your day job!)
While I doubt that McAffee has even the slightest chance of claiming the moral high ground here (or anywhere for that matter) and I have no intention of ever buying more than AV from them, it would be interesting to see an official statement of practice from them in this area.
They do say that, as does every other member of the OIS (oisafety.org). The relevant text is in the "about" section of the site:
"What does OIS think about the auctioning or selling of non-public vulnerability information?
We believe that it is unethical to intentionally make one person more vulnerable than another. Pre-release communities distribute the information too broadly for it to be kept secret. Once the word is out to some, the risk of exploit increases dramatically, but many people still don't know about the problem. While we have no illusions about the possibility of the vulnerability being known outside the vendor and researcher, we prefer not to add to that problem."
Perhaps the OIS should ratify the language from their FAQ; at least one signatory might need to resign if they do, though.
"What a ridiculous red herring. Nobody published attack code. You still don’t have access to anything beyond proof-of-vulnerability (not even proof of concept)."
yes, since it didn't happen this time the potential for it to happen must be a red herring...
@tyler reguly
"The AV companies would rather sit back and wait for the virus/worm/trojan that exploits a vulnerability then proactively find the vulnerability before the bad guys so that the vendor can properly patch it."
why do you think it sounds like that? because they would rather not participate in an exercise that requires a successful attack? you are, i hope, aware that you can demonstrate exploitability benignly, right? as an example, there have long been websites which demonstrate javascript and other associated vulnerabilities to the user without actually compromising the user's system in a meaningful way...
As I pointed out kurt... Many companies won't accept them... They want proof of the vulnerability...
Also your example of web-based vulnerabilities doesn't work. What you've done is state that you can "demonstrate vulnerabilities to the user"
To finish the above post:
All you've done is describe a proof of concept... You're trying to distinguish between a web-based vulnerability and a system vulnerability... two completely different breeds of attack... In the end though there's no difference between a malicious exploit and a PoC other than a hop, skip and a jump to change calc.exe to a listening shell.
As for companies, like Tipping Point, that pay for vulnerabilities... They are a huge benefit to the community. 5-10 years ago you saw a lot more exploits make the mailing lists and forums... Now you see (for the most part) low hanging fruit and garbage... Why? Because people have figured out that it's more worthwhile to get $10,000 from Tipping Point than it is to send a 0day to a mailing list for free... These companies are improving security for everyone... They are a great benefit to the security community and the Internet as a whole.
"Kurt, this vulnerability has nothing to do with Javascript."
i did preface that bit about javascript with the words "as an example"
@tyler reguly:
"You’re trying to distinguish between a web-based vulnerability and a system vulnerability… two completely different breeds of attack"
actually i'm not trying to draw any such distinction because i don't believe such distinctions are relevant in the context of benign exploits vs fully functional attack code...
"In the end though there’s no difference between a malicious exploit and a PoC other than a hop, skip and a jump to change calc.exe to a listening shell."
actually there is a difference... with benign exploit code you aren't directly arming the bad guys if/when the details get out... could a benign exploit be modified to be less benign? sure, so can a hello world program... you can't control what bad people do with the things you create, but there are many things you can do to avoid helping them...
that said, it looks like mcafee took a harder line with exploits than i anticipated so the distinction i was drawing between benign exploits and full attack code is moot (and, considering their history with regards to financial incentives for attack code, good for them)...
"Kurt, none of what you are talking about is relevant to the situation at hand. Can you find some other comment thread on our blog to post this stuff to? Because if you imply again that 3Com published exploit code for this vulnerability, I’m just going to delete your comment. This is getting silly."
thomas, there is clearly a fundamental disconnect between the words coming out of my keyboard and the ones you're reading on your screen... i never made the implication you're talking about (so i can't really make it 'again') and i was never even headed in that direction...
if you don't think there's relevance in the issue of paying people to produce bad things (regardless of the controls one tries to put in place) then so be it, but it's an issue the anti-virus industry in general (and mcafee in particular) started grappling with a long time ago so mcafee's position should come as no surprise...
I suppose you could be debating whether it's OK for researchers to produce "attack code" at all. You will then be debating the entire concept of security research. No mainstream AV vendor currently advocates for the end of vulnerability research, and I suspect you will find a hostile environment for that sentiment on this blog as well.
"I do not understand why you are talking about “attack code” in a thread about ZDI’s handling of the QuickTime vulnerability."
the post was about mcafee's claims that they won't touch a contest like pwn-to-own with a barge pole... the contest required that a contestant attack and successfully compromise a machine in order to win - that is where attack code comes from...
"The points you are making about vulnerability contests in general strongly imply that you believe ZDI made attack code available. Nothing of the sort happened."
you're talking about disclosure here - i made it clear in my very first sentence in my very first comment to this post that i wasn't...
"I suppose you could be debating whether it’s OK for researchers to produce “attack code” at all."
more along the lines of whether it's ok for a company like mcafee to pay 3rd parties to do so (especially people who mcafee cannot bind to subsequent responsible/ethical handling of the materials in question)...
"No mainstream AV vendor currently advocates for the end of vulnerability research, and I suspect you will find a hostile environment for that sentiment on this blog as well."
i'm not calling for the end of vulnerability research either, which is why i was at one point trying to draw a distinction between benign exploit demos and attack code that can be used by script kiddies - to underscore that there are ways to do it that should generally not be considered problematic (but which are inherently not embraced by a contest such as pwn-to-own)...
"I don’t get it. If it’s fine for people like me to independently research vulnerabilities (which requires the generation of “attack code”), why isn’t it fine for McAfee to pay me to do it?"
perhaps the root of this communication problem is the assumption that the people getting paid would necessarily be people like you...
at any rate, it's clear to me that we're operating on very different wavelengths and at this point i don't really expect to be able to bridge the gap...
So Rahul- is this your organization idea of responsible?
http://labs.idefense.com/intelligence/vulnerabi...
"VIII. DISCLOSURE TIMELINE
08/14/2006 Initial vendor notification
10/17/2006 Second vendor notification
02/07/2007 Third vendor notification
02/08/2007 Initial vendor response
05/08/2007 Coordinated public disclosure
6 months to even RESPOND to reported vulnerability in your product??? What do you say for that? Maybe McAfee should stop criticize other competitors and start working on their own policy!
"So, your concern that bounties will incite bad actors into writing attack code means that people like Dino shouldn’t get paid for their work?"
no, that's not what it means... whether or not someone deserves payment is entirely orthogonal to whether or not someone else has any place making the payment...
"Why do you care if MCAF pays Dino, versus us paying Dino?"
gee, i wonder why would anybody care about an anti-malware vendor paying for the production of what is essentially new malware? what could possibly go wrong?
I thought you were OK with vulnerability research. Now you seem to think all vulnerability research equates to creating malware. Which is it?
Also, is it OK for MCAF to pay their own researchers to find vulnerabilities (NOT the virus guys --- the guys like Mark Dowd, who find product vulnerabilities for MCAF)? It sounds like that's also a case where MCAF is paying for the production of new malware.
"Wait, you’re saying that if we pay Dino to find vulnerabilities, we’re paying to create new malware?
I thought you were OK with vulnerability research. Now you seem to think all vulnerability research equates to creating malware. Which is it?"
the pwn-to-own contest wasn't just vulnerability research, one had to launch a successful attack... are you telling me the code written shouldn't qualify as malware? is it safe to hand over to a skiddie?
(not a skilled black hat, mind you, as they could turn any exploit code into attack code)
"Also, is it OK for MCAF to pay their own researchers to find vulnerabilities (NOT the virus guys — the guys like Mark Dowd, who find product vulnerabilities for MCAF)? It sounds like that’s also a case where MCAF is paying for the production of new malware."
i've already indicated that not all vulnerability research activities are created equal... i've already indicated that there are ways to prove the existence of a vulnerability in a benign way... creating tools to compromise machines using the vulnerability doesn't fall under that category...
Bug bounty companies are not NPOs they're profit-oriented security vendors and they, eventually, must make money off the bugs they bought otherwise their business model doesn't work, that in turn means that your "raw material" is transformed into a "good" that can be sold in a "free market" that requires money to enter.
You and many others may support that model but that doesn't prove it beneficial to everybody, specially to those that may not have access to the proposed free market.