Slashdot Mirror


Why Responsible Vulnerability Disclosure Is Painful and Inefficient

A recent rant up at Attrition.org highlights problems with the responsible disclosure of security issues. While some vendors are happy to do their own research and patch reported problems, others drag their feet and make unreasonable demands on a researcher's time and effort, making anonymous public disclosure an ever-more-tempting option. Quoting: "After a couple hours of poking, I found a huge unauthenticated confidentiality hole. Once the euphoria wore off, I realized I had a big problem on my hands. I had to tell my employer's app owners and we had to assess risk and make a decision on what to do about it. After some quick meetings with stakeholders, we decided to severely limit access to the thing while we worked with the vendor. The vendor refused to acknowledge it was a security issue. Odd, considering most everyone who sees the issue unmistakably agrees that it is not acceptable. Now I'm forced to play hardball, yet nobody wants to fully-disclose and destroy relations with this vendor, whose software is somewhat relied on. Meanwhile, I know there are hundreds of institutions, small and large, using this software who have no idea that it has flawed security and who would probably not find the risk acceptable. What can I do? Nothing. Oh well, sucks to be them. ... I've had a vendor tell me to put a webapp firewall in front of their software. Did they offer to pay for it? No. That would be like Toyota telling its customers to buy ejector seats (unsubsidized ejector seats, that is) to resolve the accelerator problem in their vehicles. I've had other vendors demand I spend time helping them understand the issue, basically consulting for free for them. Have you ever knocked on a neighbor's door to tell them they left their headlights on? Did they then require you to cook them dinner? Exactly..."

7 of 182 comments (clear)

  1. Leak it by Aurisor · · Score: 4, Interesting

    Leak a working exploit anonymously. If a vendor isn't concerned with the security of their users, let them pay the price.

  2. Re:Blow the Whistle by TheLink · · Score: 4, Interesting

    And they do get away with it.

    Maybe things are different now with more hackers looking for holes, but back then you could find bugs, disclose them responsibly and privately, have the vendor/site still not fix them for years, and nobody notices - not even the hackers.

    They eventually might fix it in some future release (not even the next major release :) ). Or they replace it with something totally different.

    So nobody's hurt. At least that I knew of, which is the other problem: who knows right? Maybe a hacker did find it and was very discreet. Ignorance is bliss or not ;)...

    It's just like leaving your car unlocked somewhere with the key in the ignition. In certain areas it's a sure thing that the car will be gone the next day, but not everywhere.

    For the more obscure areas, if you do disclose it publicly, the risks to the users go up more than if you had kept it quiet.

    In the long term maybe the users would be better off using something else, but who is to say the other stuff isn't as crappy? It's not like everyone has so much time to try to exploit everything. Even the security researchers don't look at "everything".

    --
  3. There is a great forum for fixing such bugs by medcalf · · Score: 5, Interesting

    The shareholder meeting. Simply note that you reported bug # XXXX some months ago, and it has not been acted on. You wouldn't mention it except that it's a security vulnerability that, if disclosed, would tank the share price for the company. So in that light, when will this vulnerability be addressed? Let everyone else take it from there.

    --
    -- Two men say they're Jesus. One of them must be wrong. - Dire Straits
  4. Getting their attention by Animats · · Score: 4, Interesting

    It's hard getting the attention of some vendors. I see vulnerabilities in a slightly different context - hacked web sites hosting phishing pages. We distribute a list of major domains being exploited by active phishing scams. This is obtained by processing PhishTank data, and we do this because we want to reduce the collateral damage from a tough blacklist system. At any given time, there are about 30 to 80 domains on the list.

    Some sites get themselves off the list quickly. By now, most of the better free hosting services and short-URL services are automatically checking PhishTank and the APWG blacklist to see when they've been hit. Today, if you run a service where anybody can put up a page that could be used for phishing (i.e. it's not full of your own headers and banners), you need automation to deal with attacks. I've been in contact with the abuse guy at "t35.com", which is a free hosting service. They've recently been hit by a flood of phishing attacks, with several hundred new reports in PhishTank per day. The attacks were coming in faster than the abuse guy could clean them out. They're now gaining on the problem, but haven't squashed it yet. Take-away lesson: automate this.

    The ones near the top of the list have been there for a while. Note the dates, which are the date that the oldest phishing report still online and active appeared in PhishTank. Some just need help. Typically, these are small organizations like churches and nonprofits that have had a break-in and were partially taken over by a phishing site. I send them the Anti-Phishing Working Group's "What To Do if your Site Has Been Hacked". Sometimes I give them a phone call. They deserve sympathy.

    Then there are the hard cases. These are sites with no visible contact address, or a clueless abuse department. At the moment, Google Sites and Google Spreadsheets are being used for phishing. Google is new to the free hosting business, and the phishers have discovered some tricks that Google can't yet handle. While Google puts a "report abuse" link on their site pages, it's possible to set up a file for downloading on Google Sites, and an HTML page can be served that way, without Google's abuse checking. There's also an exploit of Google Spreadsheets. That one is an example of Habbo Hotel phishing. We've reported these to Google several times, but they haven't been fixed yet.

    We've been seeing a new type of attack recently - a phishing operation breaks into a shared hosting server and plants phishing pages on multiple domains on a single server. One of these hit one of the mysterious "*.websitewelcome.com" servers, which has "cloaked domain registration" and no useful default web page. These seem to be associated with "ThePlanet.com", but whether ThePlanet operates them, is providing wholesale hosting, is providing colocation, or is just the upstream connectivity provider is not clear.

    Hiding the contact information of a hosting provider is legally unwise. The hosting provider may lose the "safe harbor" protection of the the DMCA. The "safe harbor" provision for "Information Residing on Systems or Networks At Direction of Users" only applies if "the service provider has designated an agent to receive notifications of claimed infringement... by making available through its service, including on its website in a location accessible to the public, and by providing to the Copyright Office, substantially the following information: the name, address, phone number, and electronic mail address of the agent." So when the RIAA or the MPAA come calling, a likely event for a hosting service, they get

  5. Re:Blow the Whistle by commodore64_love · · Score: 4, Interesting

    It's the year 2005. You know that Toyota cars have a programming bug that causes cars to accelerate, and ignore any other inputs (ignores the brakes or switching gear to neutral). What do you do?

    It's the year 1970. You know that Ford cars have a design flaw that makes them the gas tank explode in an accident. What do you do?

    In the 1970 instance, a book author wrote a tell-all called "Unsafe At Any Speed" which revealed Ford's design flaw. In the 2005 case, I'd simply post what I discovered to Toyota-oriented websites and also call the U.S. Government Product Safety Commission. Otherwise Ford/Toyota would never have fixed the problems with their cars.

    I'd also report this software bug, since the vendor seems inclinded to pretend it does not exist. Better to be a whistle-blower and save lives than wait until damage is done. You can't resurrect corpses, but you can warn people while they're still alive, so they can act to protect themselves.

    IMHO.

    Please don't mod me down just 'cause you disagree.

    --
    "I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
  6. Inform your corporate attorney of all the facts by pem · · Score: 4, Interesting

    This is not a programming problem any more. Much as we all hate lawyers, this is one case where they are useful. VERY useful. You put him on notice, it's not your problem any more. He puts the vendors lawyer on ACTUAL notice (which has a specific legal meaning). He might even need to tell the other lawyer that he's going to have to report this issue in the next required SEC filing. IMO, if you already have the thing deployed, which it seems may be the case from your post, your FIRST stop should have been the attorney.

    1. Re:Inform your corporate attorney of all the facts by pem · · Score: 5, Interesting

      Exactly.

      And this is the right way to go about it.

      And the nice thing is that when you report it in the filing, the other company will be shamed because other people will figure out who it is, yet you are not really adding to your own risk, because in the SEC filing you use some words like have been used in this article:

      "We have discovered a security vulnerability in a third party web application platform we use. If this is successfully exploited, (list of bad things that could happen). We have informed the vendor, and they have so far been unresponsive in fixing it. We are working diligently to deploy a firewall in front of the applications, but there is no guarantee that this vulnerability will not be exploited before we have that fully deployed, or the vendor gives us a fix."

      This is exactly the chain of command/control you want to use. You tell your counterparts at the other company that your company's policy requires you to report it to the lawyer, the lawyer tells his counterpart that SEC rules require him to disclose the vulnerability, and then he does it in the next report. End of story.

      Then the ball is in the other company's court to either fix the vulnerability or prove to your satisfaction that it isn't a problem.