[Full-Disclosure] FW: Response to David Litchfield on Responsible Disclosure and Infosec Research

From: Jason Coombs (jasonc@science.org)
Date: 01/29/03

  • Next message: Richard M. Smith: "RE: [Full-Disclosure] [Secure Network Operations, Inc.] Full Disclosure != Exploit Release"
    From: "Jason Coombs" <jasonc@science.org>
    To: <full-disclosure@lists.netsys.com>
    Date: Wed, 29 Jan 2003 12:57:27 -1000
    

    -----Original Message-----
    From: Jason Coombs [mailto:jasonc@science.org]
    Sent: Wednesday, January 29, 2003 12:52 PM
    To: David Litchfield [david@ngssoftware.com]
    Cc: bugtraq@securityfocus.com
    Subject: Response to David Litchfield on Responsible Disclosure and
    Infosec Research

    Aloha, David.

    Please continue to publish proof of concept sample exploit code and disclose
    the details of vulnerabilities that you discover or analyze. The public
    receives little or no security benefit from keeping knowledge obscure, and
    closed source (secret) analysis of mistakes from the past guarantees that
    those same mistakes will be made by others in the future.

    Sapphire was a gem. With 376 bytes this worm attached a marker that screamed
    "insecure" to every computer it infected, creating a worldwide information
    security reponse focused on precisely those boxes that most urgently needed
    security hardening.

    Sapphire could have destroyed data on each computer it entered; its author
    chose not to make it do so: for this we may be lucky, or we may have
    somebody patriotic to thank for calling this threat to our attention before
    it got exploited by somebody else for the purpose of doing real harm.

    Even if you had authored Sapphire in full self-replicating form, it is the
    act of using the worm as a tool of attack that violates law. Disclosing its
    source code or its packet capture/object code should very clearly violate no
    laws. The fact that we are now faced with several laws in the United States
    that might be leveraged by an aggressive prosecutor to turn this disclosure
    into a violation of law is itself an urgent systemic vulnerability in need
    of repair. Before anyone will believe this to be the case, we need at least
    one example exploit. The Elcomsoft case was not it.

    Technology suffers from inherent radical fallibility; not unlike us humans.
    Our legal and business systems, every system we create, can be exploited and
    manipulated to cause harm or accumulate unjust riches and power. A
    well-informed and well-armed public is an essential defense against such
    manipulative abuses. Every effort to curtail disclosure, and every
    individual who concedes, pushes public engagement in and awareness of
    security analysis deeper into obscurity and illegality.

    Vulnerabilities, and the ways in which they are being exploited, must be
    published openly. Security through obscurity does not work. When
    vulnerabilities and exploits are kept secret, those at-risk are deprived of
    the opportunity to build countermeasures. There are ALWAYS countermeasures
    possible for any exploit. Nothing good comes from hiding threats from those
    who can prevent damage to their computer systems if they knew of the threats
    in advance.

    Every attack involves at least two people, and in virtually every
    circumstance of attack either one of those people could have prevented it in
    advance. Often times attacks are made possible because the victim does not
    understand the risk posed by their reliance on a system created by somebody
    else. This is true of infosec vulnerability exploits just as it is true of
    all other harms that people do to other people in the physical world. There
    should be no doubt that supplying education and detailed technical training
    freely and to all people increases the potential for security. Everyone
    should analyze security threats that exist in the systems they rely on that
    were created by other people -- whether those systems are based on computer
    networks or based on laws and methods of government. The detailed technical
    reasons for currency collapse and other geopolitical and financial threats
    are always disclosed in full and analyzed completely by economists and
    academics, and these events cause far more real-world damage than a simple
    information security exploit. The idea that publishing detailed technical
    descriptions of the vulnerabilities in a system of economics or the
    practices of a financial market is in and of itself harmful simply because
    somebody is enabled through this knowledge to exploit the vulnerabilities
    misses the point that without disclosure there would be no chance of repair
    and defense. Those social engineers (legislators, politicians, influential
    business leaders, etc.) who are responsible for protecting against threats
    to the systems to which they tend will have no opportunity to redesign
    vulnerable systems if a period of time does not elapse during which the
    vulnerability is discussed and analyzed widely.

    Every time a vendor publishes a fix for a security bug, the fix itself
    discloses the vulnerability in detail -- to black hats, malicious hackers,
    and to information security experts who take the time to conduct full
    forensic analysis of the changes from the previous version of software to
    the bug-fixed version.

    Attempting to keep vulnerabilities secret while simultaneously releasing bug
    fixes for them is harmful to security. If secrecy worked, it would be far
    better for vendors NOT to release bug fixes and for nobody to talk about
    information security threats. Obviously this is not practical, or
    reasonable, therefore full disclosure is the only solution.

    We all know code and knowledge we release will be used to do harm if it is
    possible for it to do so. If I were the prosecutor, I'd bring charges
    against anyone who releases any code, and some who release knowledge, on the
    basis that there was specific foreknowledge as to harmful uses. The Patriot
    Act, DMCA, and Computer Fraud and Abuse Act would give me legal grounds to
    do so -- as prosecutor it would be my job to exploit the law not interpret
    or
    judge it. There is every reason to believe that more prosecutors will push
    forward with such cases against those who disclose vulnerability details and
    in particular those who disclose proof of concept code.

    Careful, thoughtful, and articulate full disclosure of vulnerabilities and
    proof of concept publication is ethical and necessary. You must have a
    detailed understanding of the DMCA, Patriot Act, and Computer Fraud and
    Abuse Act to continue this practice in the U.S. Even if you think you
    understand these laws clearly, study them in detail yourself just as you
    would conduct any vulnerability or social engineering threat analysis and
    consider the legal vulnerabilities they create for you as an infosec
    researcher when they are combined aggressively to prosecute you for what you
    have done. You do in fact put yourself at risk by disclosing vulnerabilities
    and publishing proof of concept code. There just isn't sufficient case law
    at this time for optimists to understand the risks. As a proper pessimist,
    you are in a much better position to appreciate the worst case scenario --
    Sapphire having been based on your published code may already be setting in
    motion that worst case scenario for you. Hopefully not. Your only defense
    under law is proof that your research and publication methods meet an
    objective evidence test establishing beyond reasonable doubt that your acts
    and the resulting disclosure were entirely consistent with information
    security and/or cryptography research -- and urgently necessary to enable
    proactive defense against attacks. Have this evidence ready just in case
    it's needed.

    Victims of exploits should report specific incidents of attacks they have
    suffered because after the fact they are no longer vulnerable to this same
    attack, but others still are, and sharing this information helps everyone to
    defend themselves. Further, the information security community provides
    assistance and advice to those who have become victims of exploits. The
    quality of this open analysis of the reasons for and defenses to an exploit
    or vulnerability is superior to paid information security consulting in
    secret in virtually every case because more eyeballs make certain that every
    nuance of a threat is articulated.

    While some end-users were inconvenienced by the Sapphire worm, every
    end-user benefits from the security hardening that occurs in response to
    this type of exploit. The network is safer now, for everyone, than it was
    just three days ago. Without the Sapphire worm, we would not have recognized
    and repaired extremely important vulnerabilities in our global information
    security infrastructures.

    As for companies and critical infrastructure (e.g. ATMs, Continental
    airlines, American Express, Microsoft) that go down in the face of worm
    attacks that exploit vulnerabilities we disclose -- There is no execuse for
    any important information system to rely exclusively on or be exposed
    indirectly to the Internet. Failover routes must be in place for important
    services; the Internet can be used safely for important business services
    only when appropriate security and fault tolerance countermeasures are
    implemented. The Sapphire worm was successfully blocked by the simplest and
    most common information security device: the firewall. The fact that so many
    networks were vulnerable to Sapphire illustrates blatent disregard for
    security and proper fault tolerant system engineering design principles by
    many organizations in favor of quick and simple worker productivity
    solutions.

    Full disclosure made directly to those who care enough about security to
    read security alert and advisory documents like this one is an effective way
    to communicate vulnerability details to those who most urgently need them
    and who are most likely to act upon them.

    THE MOST IMPORTANT MITIGATING FACTOR IS ALWAYS AN INFORMED POPULATION
    THAT IS READY, WILLING, AND ABLE TO ACT WHEN ACTION IS REQUIRED TO ENSURE
    THE SECURITY AND INTEGRITY OF INFORMATION SYSTEMS AND PROTECT STAKE-HOLDERS
    WHO WOULD OTHERWISE BE BOTH AT-RISK AND UNINFORMED; IT IS IRRESPONSIBLE FOR
    A SECURITY RESEARCHER TO TRUST SOMEBODY ELSE TO DISSEMINATE IMPORTANT
    INFORMATION ABOUT NEW VULNERABILITIES AND IT IS FURTHER IRRESPONSIBLE FOR A
    PERSON WHO KNOWS OF A SECURITY VULNERABILITY TO KEEP IT SECRET FOR A
    PROLONGED PERIOD OF TIME IN THE IRRATIONAL AND NARCISSISTIC HOPE THAT NOBODY
    ELSE IS SMART ENOUGH TO FIND THE SAME VULNERABILITY.

    A small, highly-skilled and diligent distributed group of
    self-coordinating, self-organizing infosec experts who know each other and
    communicate freely is far more capable of responding to security incidents
    and moving forward any and all preventative measures necessary to minimize
    the security risk and imminent dangers of any infosec threat than are dozens
    of people and organizations compromised by politics and fear. To ensure
    continued high-quality, timely, and accurate vulnerability disclosure
    requires peer-reviewed communication free from restrictive and oppressive
    forces. Those who pose a threat to information security have this freedom to
    communicate because they take it or they make it even though it requires
    them to take personal risk. For information security professionals and the
    United States Government to deny themselves, their employees, and citizens
    this same freedom as a defense against attack is not only counter-productive
    it is also insane.

    The DMCA section 1201 "Circumvention of copyright protection systems"
    also includes provisions for "PERMISSIBLE ACTS OF ENCRYPTION RESEARCH".
    There should be no concern on the part of any security researcher or
    cryptographer that communicating the results of an ethical information
    security analysis might result in arrest and prosecution for violation of
    the DMCA or other laws. THE DMCA DOES NOT TRUMP THE FIRST AMENDMENT.

    Like an IETF Working Group or an open source or free software/GNU
    development effort, anyone who wishes to do so and who has something of
    value to contribute can contact infosec peers and solicit the forensic
    analysis help of any other security coordinator, infosec, or forensics
    expert without fear of prosecution for criminal conspiracy. In practice,
    contacting a vendor expecting forensic analysis assistance is futile;
    vendors will take a new vulnerability report and conduct their own forensic
    analysis but won't reveal additional aspects of a vulnerability to you
    because you are untrustworthy. The vendor has no incentive to spread
    vulnerability information and you have no "need to know" more than the
    vendor chooses to tell you about the scope of the vulnerability you
    discovered. Entrusting vendors with exclusive possession of vulnerability
    details is counterproductive to the desired end-result of secure information
    systems and properly hardened security policies; the analysis capabilities
    of security researchers who are not restricted by employment contracts,
    confidentiality agreements, and other impairments are superior in every
    respect and in every instance thus far examined by this author.

    Sincerely,

    Jason Coombs
    jasonc@science.org

    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html



    Relevant Pages

    • Re: [Full-Disclosure] RE: Disclosure policy in Re: RealPlayer vulnerabilities
      ... you wrote that I do not really believe in "full disclosure" ... Vulnerability is discovered and the vendor is notified. ... I am not talking about the absolute security. ... you say that vendors must work much harder at reducing patch ...
      (Full-Disclosure)
    • RE: [Full-Disclosure] Sapphire worm POC that fulldisclosure policies hurt everyone
      ... point from which to conduct vulnerability analysis. ... When a vendor releases a security patch or a service pack that includes some ... Publishing security fixes without full disclosure of what's being fixed is ... Sapphire worm POC that fulldisclosure ...
      (Full-Disclosure)
    • RE: Can we afford full disclosure of security holes?
      ... Can we afford full disclosure of security holes? ... black hats are free to exploit the vulnerability until the vendor ...
      (Bugtraq)
    • Re: [Full-disclosure] University of Central Florida Multiple LFI
      ... true of UCF. ... When Berkeley had a gaping hole in their security which allowed ... with the vulnerability itself being patched within 18 hours; ... consider their stance on Full Disclosure as a disclosure policy. ...
      (Full-Disclosure)
    • Re: Professional Scrpt Kiddies vs Real Talent
      ... Infosec is so much more than finding vulnerabilities in products that you can hardly ... limit a list of "security experts" to people doing vulnerability research. ... I disagree with your position that any serious security services provider HAS TO DO security research (vulnerability research and exploit development). ... Information Assurance Certification Review Board ...
      (Pen-Test)