McAfee: For Us, It’s Internet First, Then Customers — Unlike 3Com!

Thomas Ptacek | May 7th, 2007 | Filed Under: Disclosure, Industry Punditry, Uncategorized

Rahul Kashyap at McAfee takes 3Com to task for the QuickTime drama:

The anti-virus community, long the target of (bogus) claims that they write viruses to make money, wouldn’t touch a contest like this with a barge-pole. In fact, even staunch full-disclosure advocates note the ethical disconnect implicit in security companies producing content earlier than their competitors via such initiatives

I say, God bless him! It’s good to draw lines in the sand. In fact, we did exactly that, last year, with a public disclosure code of conduct. So, more specifically, my response to Rahul is a challenge. If McAfee wouldn’t touch a contest like CanSec’s PWN-TO-OWN, what would they do? If McAfee pledges to protect the Internet at large, and pledges not to prioritize their own customers, they should say that.

Rahul, can you please post a link to McAfee’s disclosure code of conduct? It sounds like you’ve thought a lot about it. I’d love to see what it is.

(PS: I think your problem is with the Zero Day Initiative, not with the contest itself.)

[Update: 2:35EST]

Did Rahul do his homework? 3Com doesn’t think so! A presumably official response to McAfee from the Zero Day Initiative, in our comments. I’ll note: this ZDI showdown is long overdue. What do you think, Rahul?

Viewing 34 Comments

    • ^
    • v
    Um, ZDI _did_ provide Apple with the vuln details and did give them a chance to fix these flaws before their _coordinated_ disclosure. In fact, Apple’s updated QuickTime packages hit their update servers at the same time ZDI disclosed the vulnerability.

    The good folks at McAfee need to get their facts straight.
    • ^
    • v
    i don't think it's a disclosure issue, i think it's a matter of providing an incentive for people to produce attack code... providing such an incentive would be only a hop-skip-and-a-jump away from producing such code themselves (which people claim they do anyways, but as he says, such claims are bogus)...

    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...
    • ^
    • v
    <strike>What a ridiculous</strike> red herring. Nobody published attack code. You still don't have access to anything beyond proof-of-vulnerability (not even proof of concept).
    • ^
    • v
    Disclaimer: TippingPoint is a competitor to McAfee in the IPS space.

    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.
    • ^
    • v
    I think there's a difference between the AV industry and "Security" industry... Finding "attack code" is crucial... especially for the Good guys to do...

    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.
    • ^
    • v
    re: AV vs. Security -- in fairness the security industry is trying to fix a solvable problem and the AV community is tasked with protecting you against an unsolvable problem. Preemptively finding, notifying the vendor and fixing security problems results in progress. That doesn't work in the AV community. If I find a new way to write a worm, write one up, and write a signature for it, there is no added protection to end users than before the new virus was created. The virus detection problem is no less "undecidable" after disclosing the new worm.

    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!)
    • ^
    • v
    Somehow the idea of bug bounties by outside parties still makes my skin crawl. Some bits of my employer use TippingPoint, but I'll do my best to keep my branch's cash out of their hands.

    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.
    • ^
    • v
    "...If McAfee pledges to protect the Internet at large, and pledges not to prioritize their own customers, they should say that."

    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."
    • ^
    • v
    That text doesn't appear in their "standard", the "Guidelines for Security Vulnerability Reporting and Response". I'll add that a small fraction of all vuln research is "compliant" with this standard.

    Perhaps the OIS should ratify the language from their FAQ; at least one signatory might need to resign if they do, though.
    • ^
    • v
    Also: auctions and bounties make my flesh crawl too. We don't do it.
    • ^
    • v
    @thomas ptacek:
    "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...
    • ^
    • v
    Kurt, this vulnerability has nothing to do with Javascript.
    • ^
    • v
    @kurt

    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"
    • ^
    • v
    *Mental Note... don't include 'less than, hypen, hypen in posts*

    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.
    • ^
    • v
    Markets make everything better!!!
    • ^
    • v
    @thomas ptacek:
    "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)...
    • ^
    • v
    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.
    • ^
    • v
    @thomas ptacek:
    "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...
    • ^
    • v
    I do not understand why you are talking about "attack code" in a thread about ZDI's handling of the QuickTime vulnerability. 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.

    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.
    • ^
    • v
    @thomas ptacek:
    "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)...
    • ^
    • v
    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? Is vulnerability research like sex?
    • ^
    • v
    @thomas ptacek:
    "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...
    • ^
    • v
    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?
    • ^
    • v
    This sounds like the legality of gun ownership debate.
    • ^
    • v
    I post this to Avert Labs. They probably delete.

    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!
    • ^
    • v
    @thomas ptacek:
    "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...
    • ^
    • v
    Why do you care if MCAF pays Dino, versus us paying Dino?
    • ^
    • v
    @thomas ptacek:
    "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?
    • ^
    • v
    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?

    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.
    • ^
    • v
    @thomas ptacek:
    "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...
    • ^
    • v
    So what's the difference between the GOOD vulnerability research that MCAF does, which generates attack code for vulnerabilities, and the BAD vulnerability research that Dino did?
    • ^
    • v
    Difference is that MCAF is a company that serves a few, and independant researchers serv a bunch, so naturally those few are pissed. Really campanies hate to see researchers being paid, they just want to get everything free, treating researchers like crap(MICROSOFT specially) just becouse they want to earn something for their research, they see 0 day initiative like a threat to them, hoping that if no one pays researchers one day they will get tired and leave there products alone for them to control the information. Wanting to get paid for vuln research is expectable, its a hard demanding that involves many hours, its good to be abl e to sell that information to others than spammers.
    • ^
    • v
    No mainstream vendor treats security researchers better than Microsoft does.
    • ^
    • v
    @anonym: if you are a vuln. researchers and want to get paid to do it then go get a job as vuln. researcher. If you do it to save the world or as a hobby or because you are a really nice guy or accidentally then do not come saying that you would do it for the bounty. You can't have it both ways.
    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.

Trackbacks

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus