Slashdot Mirror


When Is It Right To Go Public With Security Flaws?

nk497 writes "When it comes to security flaws, who should be warned first: users or software vendors? The debate has flared up again, after Google researcher Tavis Ormandy published a flaw in Windows Support. As previously noted on Slashdot, Google has since promised to back researchers that give vendors at least 60-days to sort out a solution to reported flaws, while Microsoft has responded by renaming responsible disclosure as 'coordinated vulnerability disclosure.' Microsoft is set to announce something related to community-based defense at Black Hat, but it's not likely to be a bug bounty, as the firm has again said it won't pay for vulnerabilities. So what other methods for managing disclosures could the security industry develop, that balance vendors need for time to develop a solution and researchers' needs to work together and publish?"

6 of 126 comments (clear)

  1. I wrote my quick thoughts up the other day .... by Kalidor · · Score: 5, Interesting

    ... and posted them elsewhere. So here's a quick copy paste and what my thoughts are.
    ======================
    Procedure :
    Step 1) notify manufacturer of flaw

    Step 2) Wait an appropriate time for response. This depends on the product. OS could be as much as months depending on how deep the flaw is. Web-browsers probably 2-3 weeks.
    Corollary 2a) If manufacturer responds and says its a will-not-fix you have some decisions, see 3a.

    Step 3) If no response, make an announcement of doing a proof of concept exhibition with a very vague description. People asking for details say it was probably as vague as possible. The company has already been contacted, so they know the issue or can contact you from the announcement. Schedule it with enough time for the company to release a fix.
    Corollary 3a) How critical is the flaw. If marked as will-not-fix and its very detrimental you might have to sit on it.

    Step 4) Do exhibit. With luck flaw has been fixed and last slide is about how well manufacturer did.

    Step 5) ...Profit!!!! (While this is the obligatory joke post, Check out E-Eye security to see how it's happened before)
    ===============
    WRT to 3a: You'd be surprised how often this is done. There are two long-standing issues against a certain software that, while being uncommon and not often thought of attack vectors, are less than trivial to exploit and gain full access. Manufacturer has, in fact, responded with a "works as designed, will not fix." People in the information securities industry have found the flaws so detrimental that they've imposed a self-embargo about openly discussing it. Without manufacturer buy-in, a fix just can't come in time if that particular information was released and the effect would be significantly widespread. The only thing releasing the information would do is cause a massive Zero Day event that would only harm consumers or leave them without the services of the software for several months. With no evidence that the exploit is being used in the wild, save for handful of anecdotal reports, the issue has become a bi-annual prodding of the manufacturer.

    --

    Code softly but carry a big magnet.

  2. When the company will not listen by RJarett · · Score: 5, Interesting

    I discovered a large DoS within VMware 3.5-4.0 last march. I opened up a support case on it to at least find a workaround. The engineer closed the ticket after an hour or 2 as "unsupported OS".

    The DoS reboots ESX/ESXI out from under the VM when you power the VM on.

    This leads to serious issues, and the closed the ticket quick. No further investigation. This is a perfect example of releasing details and source to force the company to fix the issue.

  3. It's not fair by Anonymous Coward · · Score: 3, Interesting

    to threaten the guys who find vulnerabilities with jail time or fees. I uncovered a major security flaw in a piece of software (allowed an attacker to spawn a shell as root with extreme ease) and also found a way to circumvent the DRM and what happened.... I got stiffed. Instead of FIXING the problem (which is still intact to this day) the company attempted to sue for copyright infringement, among a few other "charges". Luckily, I had a great lawyer and I had documented EVERYTHING from 0 to 60. I was lucky.

    This makes me sick. One minute, corporations are talking about providing "rewards" for unearthing flaws/vulnerabilities and then the next, they are trying to sue for every penny. If it wasn't for us, their systems wouldn't last a week without some script kiddie coming along and bringing the whole thing to it's knees.

  4. Re:I wrote my quick thoughts up the other day .... by Anonymous Coward · · Score: 3, Interesting

    I like especially how this ignores the human angle and assumes that all involved parties are even able to shut up for years (well, I don't know, maybe they receive... err... gratitude to shut up).

  5. Good, but you missed a step by hAckz0r · · Score: 5, Interesting

    You need to notify CERT, and then they have the ability to apply more pressure on the manufacturer, as they simultaneously publish a very vague notice to the community of a flaw being worked on. If CERT is involved you have a much higher probability of not being ignored or told "will-not-fix" because it is already public knowledge that there is an exploit that needs fixing. Its in the record. The official "report cards" for the vendors then have the clock start ticking the minute you report the flaw, and the vendor can not deny that they were notified and/or aware of the problem. In other words, they can't sweep it under the rug very easily, and you have done the best you can do without causing mass pandemonium.

  6. Re:Deadline always isn't feasbile by Rockoon · · Score: 3, Interesting

    This may not be ideal from the vendor's point of view, but it's not the vendor who's in danger of having their systems attacked so I'm not overly concerned about their public-relations heartburn.

    If you are not concerned about the vendors public-relations, then why release at all? It seems to me that the justification for release is precisely that the researchers ARE concerned about the vendors public-relations.. intent on harming it.

    Its end users that dont follow security issues that are most at risk, where the releasing of exploits hurts them pretty much directly and immediately.

    If its a critical bug in software that a typical grandma (and other non-geeks) uses, I claim that it is ALWAYS irresponsible to release the details of the exploit into the wild. Every single time, no matter how much time has passed waiting for a fix. This belief is formulated on the premise that the vendor's public-relations dont mean shit either way , that its the end users that mean something.

    --
    "His name was James Damore."