originally at: http://www.synthesis.net/tech/fulldisclosure/index.html

Full Disclosure - Effective or Excuse?

A comprehensive look at the practice of Full Disclosure, problems associated with it for vendors and security companies, and examples of full disclosure put to the test. (3300 words)

     "The Solaris Operating Environment has been carefully
      engineered to deliver a reliable, high-performance,
      scalable, and secure platform on which to develop
      and deploy desktop and server applications."

     [In a colorful bar chart:] "35% Lower TCO, 30% Faster,
      1/3 Fewer helpdesk calls, Strong Security."

• 'Regression Testing'. When bugs are reported for a specific version of a piece of software, the vendor is obligated to test and fix ALL affected versions. Once all vulnerable versions are identified, patches must be developed. Next, full tests must be run on previous versions of the software with the new patches to assure the new changes don't affect other aspects of the software.
  
  
• Architecture. In today's software world, dozens of different hardware platforms exist. Patches for the PC platform are different than those for Sparc hardware. NT patches for the Alpha vs PC could include a wide variety of alterations.
  
  
• Additional bugs. A handful of software vendors learned via trial by fire that a hasty fix is not always a quality fix. Days after the initial bug was reported and fixed, slight variations of the same bug surface days later providing a healthy dose of mud to the vendor's face.
  
  
• Beuracracy. Software companies are often big, and full of internal procedure. Departments don't always play well with others.
  

• In one case, a security company provided a large Unix vendor with a full technical writeup, working (and commented) exploit code, and half an hour explanation of the bug over the phone. Despite all of this, the technicians at the vendor still could not figure out how it all worked. Up to a year later, the vendor was still seeking assistance in getting the exploit to work.
  
  
• In 1998, the same security company worked with another large Unix vendor with a nasty remote exploit that gave attackers full access. During the exchange of information, the security company asked if they could get a "thanks" or some kind of credit in the advisory the vendor would eventually release. Despite releasing their own advisory carefully timed to coincide with the vendor, and despite hours of tech support, the vendor still would not give the company credit. Subsequent security newsletters quoted the vendor as the original poster of the bug information, not the security company.
  
  
• After a miscommunication between security company eEye and software vendor Microsoft over the public dissemination of vulnerability information, Microsoft representatives attempted to place all blame on eEye at a public convention. Without the presence of any eEye employees, a Microsoft spokesperson stood up during the Full Disclosure track at the Black Hat Briefings and proclaimed that Microsoft was the wounded dog, being kicked by big bad eEye Security. The miscommunication? A twenty four hour difference on when to post the information to public forums.
  
  

          Sun   Microsoft               Sun   Microsoft
Nov 1998   2        1         May 1999            6
Dec 1998   3        3         Jun 1999   2        5
Jan 1999            2         Jul 1999            3
Feb 1999   3        5         Aug 1999   1*       6
Mar 1999            3         Sep 1999   1        9
Apr 1999            2         Oct 1999            1

* Reprint of CERT Advisory

    "Full disclosure is in and of itself a means to an end. Many people
    participate in it not out of malice, but out of the hope that with
    enough public scrutiny vendors will finally take responsibility for
    the software they write.

    Make no mistake about it, full disclosure is ugly. People get hurt,
    however, I see no reasonable alternative. For every responsible bug
    reporter out there it's likely he/she has a counterpart who will most
    likely keep the information for themselves and use to ends that we would
    all rather avoid. 

    In a perfect world vendors would perform rigorous security audits,
    previous to market release. In a perfect world we would still have
    buggy software (this is something we will never lose) but we would
    also have vendors who make security a pre-emptive consideration as
    opposed to a forced reaction."

    Let me clarify our disclosure policy. Some people get the impression
    we are full disclosure extremist. We are not.

    First, we rather you work with the vendor to create a patch or fix
    to the problem. If the vendor is responsive and they are making a
    good faith effort to release a fix in a timely manner we rather you
    keep the existence of the vulnerability secret until such a time when
    the vendor has the fix ready. You can then release both the
    vulnerability information and patch at the same time. The reasoning
    behind this is two fold. First in our experience saying a vulnerability
    exists but not releasing full information seldom stops attackers from
    obtaining details of the vulnerability. Attackers will research the
    problem and either come up with the information on their own or will
    hack their way to someone with details of the vulnerability.

    Second, releasing both the details and the fix at the same time
    minimizes the time attackers have to find the vulnerability on their
    own. Next, we like that people post full details of the vulnerability
    once the vendor has released a fix or a patch. The reason behind this
    is that once patches are out attackers can easily reverse engineer
    them figure out what the vulnerability was. Thus you are only keeping
    in the dark the good guys. Knowing the vulnerability details allows
    people to verify that fix indeed fixes the vulnerability (we seen many
    cases where it doesn't, or it does so in a bad way), it allows people
    to look for similar vulnerabilities in other systems, and it allows
    people to learn from the mistakes that enabled the vulnerability."

    The adoption of Full Disclosure is an ethic, our responsibility and 
    the duty of every security professional is to disclose the facts. How 
    and when we disclose the facts is on the other hand the most crucial 
    part of full disclosure. Many factors come into play, the seriousness 
    and implications of the bug, how long has it been since it was discovered, 
    how responsive is the vendor and how dependant are we on the vendor for 
    a patch.

    We look at a network security breach as a violation of our safety and
    privacy and we will continue to tactically plan and execute to make sure
    that we address the issues in the shortest amount of time possible. Vendors
    are becoming more aware, end users are becoming more informed and our
    networks are becoming more secure. 

    "We try to aggressively pursue any security bug, verify it within
     our operating system, issue an immediate temporary fix and release
     a correct solution as well as a security advisory as soon as possible.
     It tends to operate on a timeframe based on hours not weeks."