Companies adapt to a zero day world
Deborah Radcliff Jul 13 2004
Zero day exploits are upon us. Case in point, the June 25th Russian attacks that turned IIS servers into delivery platforms for identity-thieving Trojan keystroke loggers. The attacks relied on two vulnerabilities in Internet Explorer that security researchers discovered for the first time weeks earlier on a malicious adware-implanting website. At the time of the attack, no patch was available.
How Should Researchers Handle Exploit Code?
By Larry Seltzer April 29, 2004
Nobody really knows where worm authors go shopping for exploits to develop, but it's widely assumed that they are greatly assisted by exploit code released by legitimate researchers.
Controversial Microsoft Security Fixes Have Company on Security Defensive
Paul Thurrott InstantDoc #41744 February 11, 2004
But Maiffret has described the lag time between eEye's discoveries and Microsoft's fixes as "just totally unacceptable." Microsoft defends the time it took to fix the flaws--a whopping seven months--as necessary, because the company needed to ensure that a patch to such central Windows components didn't break software or cause other problems. "We really took the steps to make sure our investigation was as broad and deep as possible," says Microsoft security program manager Stephen Toulouse.
Is finding security holes a good idea? (Draft)
Eric Rescorla 2004/01/21 (PDF) 16 pgs
Researchers, poll spark response to Microsoft security
By Shawna McAlearney, Staff Writer 19 Dec 2003
Several weeks ago Chinese researcher Liu Die Yu posted several Internet Explorer flaws to the Full-Disclosure security mailing list. His reasoning: Microsoft hasn't given him credit for prior vulnerabilities he reported.
Whatever individual feelings on disclosure, a recent Security Wire Perspectives minipoll reveals that 60% of our readers who responded don't think Microsoft is doing enough to address OS and application patch management issues. Nearly 70% don't believe Microsoft is doing enough to improve its software security.
PivX denies Microsoft involved in removal of IE vulnerabilities page
Security solutions provider PivX Solutions has denied that Microsoft in any way influenced a decision to remove from its website a page which listed a fair number of unpatched vulnerabilities in Internet Explorer.
Computer Security Dictionary:Full Disclosure
Exploit Code on Trial
By Kevin Poulsen, SecurityFocus Nov 23 2003
Security pros gathering at a Stanford University Law School conference on responsible vulnerability disclosure Saturday harmonized on the principle that vendors should be privately notified of holes in their products, and given at least some time to produce a patch before any public disclosure is made. But there was pronounced disagreement on the question of whether or not researchers should publicly release proof-of-concept code to demonstrate a vulnerability.
Security expert proposes hackers' union
By Robert Lemos CNET Nov. 22, 2003
A proposal to create an association to represent the interests of hackers and vulnerability researchers is gaining support, a security expert said Wednesday.
The group, which would be geared toward researchers and not software vendors, would provide guidelines on vulnerability disclosures and would lobby against legislation that could stifle security researchers' ability to tinker with software. Nearly three-dozen people have pledged financial support to help get the yet-unnamed group started, said Thor Larholm, senior security researcher for PivX Solutions.
Panel defends flaw disclosure guidelines
By Robert Lemos Staff Writer, CNET News.com July 30, 2003
A group formed to set rules for disclosing information about security flaws on Wednesday defended its latest revision and called for researchers to adopt its guidelines.
The Organization for Internet Safety (OIS) held a panel discussion at the Black Hat Briefings security conference here to field questions regarding its latest attempt to create a standard way for security researchers to report flaws to software vendors. Currently, researchers handle flaw information in widely different ways. Some immediately publish the information on the Internet, while others work with software makers to fix the issues.
Hackers, software companies feud over disclosure of weaknesses
By Doug Bedell The Dallas Morning News July 14, 2003
Under pressure to shore up the nation's computer systems from external threats, the federal government is now siding with Microsoft against full disclosure.
Group Releases Anti-Disclosure Plan
Posted by michael on Saturday June 07, 2003
dki writes "SecurityFocus reports that the Organization for Internet Safety (OIS), a group of 11 of the largest software and security companies, has released a public draft of a proposed bug disclosure standard. The document outlines a process for reporting and disclosing bugs that aims to eliminate releasing exploits to the general public. Not surprisingly, the OIS was founded out of a Microsoft-hosted security conference. Comments on the draft will be accepted until July 4th; the final copy will be released at the Black Hat Conference in Las Vegas."
Group Releases Anti-Disclosure Plan
By Kevin Poulsen, SecurityFocus Jun 4 2003
A group of 11 of the largest software companies and computer security firms released the first public draft of a proposed bug disclosure standard on Wednesday, and asked the security community for comments.
The 37-page document sets out a detailed timeline for security vulnerability reporting, and standardizes the interactions between security researchers who find bugs and the software companies who write them. The group hopes to see the final version of the plan gain widespread industry acceptance.
Security Vulnerability Reporting and Response Process
Organization for Internet Safety Public Review Version 04 June 2003
This document provides a reference process for a vendor’s investigation and remediation of potential security vulnerabilities in its products, as reported to it by security researchers, customers, and other interested people and organizations. This document also provides a reference process for individuals and organizations that report security vulnerability information to product vendors and the public.
Conspiracy theories abound in security mailing list launch
By John Leyden Posted: 26/03/2003
The Secunia Security Advisories list is based on more than 200 different sources of security information, including VulnWatch and Full-Disclosure. All the advisories on the Secunia Security Advisories list are written, verified and qualified by Secunia staff based on security research made by the security community and Secunia's own security staff.
Security Mailing Lists Come Under Fire
By Dennis Fisher March 25, 2003
"The problem with SecurityFocus is not that they moderate the lists, but the fact that they deliberately delay and partially censor the information," said Thomas Kristensen, chief technology officer of Secunia, based in Copenhagen, Denmark. "Since they were acquired by Symantec, they changed their policy regarding BugTraq. Before they used to post everything to everybody at the same time. Now they protect the interests of Symantec, delay information and inform their customers in advance. This is a problem as only companies who pay over $30,000 can get access to this information."
CERT, Feds Consider New Reporting Process
By Dennis Fisher March 24, 2003
Government officials and private organizations alike are reviewing their vulnerability disclosure processes after several incidents over the past 10 days exposed major shortcomings in the way new bugs are handled.
The most dramatic case for change came early last week when an anonymous member of a security mailing list posted three unpublished vulnerability advisories. None of the advisories had been released by the authors—or by a third party such as the CERT Coordination Center—who typically handle such announcements. The posts were taken from advance copies of the advisories that CERT had shared with a select group of software vendors, something that has angered CERT officials.
Slammer: Why security benefits from proof of concept code
By John Leyden Posted: 05/02/2003
The UK security expert who discovered the flaw which was exploited by the Slammer worm has concluded it does more good than harm to publish proof of concept code.
In a posting to BugTraq, David Litchfield of NGSSoftware expressed concerns that his proof of concept code was used as a template by unknown vandals in creating the destructive Slammer worm.
NGS Software to Cease All Future Work With CERT
By Dennis Fisher February 3, 2003
A prominent security vendor that is well-known for finding dangerous vulnerabilities in software said last week that it will no longer work with the CERT Coordination Center after becoming disillusioned with the organization's policy of giving some people advance notice of new vulnerabilities.
Expert weighs code release after Slammer
By Paul Roberts, IDG News Service, Boston Bureau 01/30/2003
Saturday's Slammer worm was based on sample code published to help explain the threat posed by the security vulnerability that Slammer exploited, according to David Litchfield, the security expert who discovered the vulnerability.
Re: David Litchfield talks about the SQL Worm in the Washington Post
David Litchfield david@ngssoftware.com BugTraq Posting Jan 29 2003
On analysis of the code of the Slammer worm it is apparent that my code was
used as its template.
Exploit Code At Security Focus Removed
by Derek Vadala Jan. 9, 2003
Looks like the exploit code from the Security Focus (i.e. Bugtraq) vulnerability database has been removed. There used to be an _exploit_ tab between _discussion_ and _solution_ on the individual vulnerabilty pages. It provided exploit code, if available. This was extremely useful for doing vulnerability testing so it's too bad. Seems to me that this is just one less resource for white hats and one more advantage for the blacks hats. I wonder if the recent acquisition by Symantec had something to do with the change.
All bugs are created equal
By John Leyden, The Register Dec 12, 2002
Security tools vendor ISS has promised to handle security vulnerabilities affecting open source and Windows platforms the same way following criticism of its premature disclosure of open source security problems.
ISS is a founding member of the Organisation for Internet Safety (OIS), whose guidelines on disclosing security vulnerabilities are backed by Microsoft. This, together with its handling of various open source vulnerabilities, have cause critics to question ISS' motives.
The Debate over Full Disclosure of Security Vulnerabilities - an Analysis of Microsoft's Limited Disclosure Proposal
John Budoff, Brian Smith, Francisco Velez, Tisha White (PDF) 12 pgs
Is Microsoft's proposal for limited disclosure of newly discovered security vulnerabilities the
best guideline for the industry to follow? To address this question, this paper looks at the debate
over vulnerability disclosure from several angles. First, it covers the background, framework,
and history of this debate. It then analyzes some of the major arguments for and against full
disclosure. Next, it explores the specific proposal that Microsoft is advocating for limited
disclosure. Finally, it presents data from a case study of vulnerabilities found in Microsoft's
Internet Information Server (IIS).
ISS Goes Public with Disclosure Policy
By Ryan Naraine December 3, 2002
In the face of public criticisms over its handling of software security alerts, Atlanta-based Internet Security Systems (Quote, Company Info) on Monday went public with its Vulnerability Disclosure Guidelines, maintaining subscribers to its X-Force Threat Analysis Service will be warned of new vulnerabilities one business day after the affected vendor is notified.
Controversy Surrounds Huge IE Hole
Posted by CmdrTaco on Tuesday November 19, 2002
Suchetha wrote in with a Wired News bit talking about security hole in IE that allows malicious web pages to reformat a hard drive. The Wired talks more about bugtrack's handling of the whole thing, and how it essentially posted working code for the exploit. Was it irresponsible or not?
How Much Hack Info Is Too Much?
By Michelle Delio Nov. 19, 2002
To disclose or not disclose -- it's a question that's been under heavy discussion in the computer security industry over the past year.
U.S. cybersecurity director Richard Clarke and virtually all software companies insist that software vendors should have a chance to fix problems before security researchers disclose them publicly.
Researchers counter that without full disclosure, companies often fail to swiftly patch security holes. Full disclosure, in theory, also alerts computer users to problems that are already known to malicious hackers, who often exploit holes before patches become available.
Do Bug-Hunting Security Firms Put Users at Risk?
Publicizing software flaws before reporting them to the maker could help hackers attack, some insiders say.
Paul Roberts, IDG News Service October 30, 2002
When researchers at GreyMagic Software discovered a batch of security vulnerabilities in Microsoft's Internet Explorer earlier this month, their first response was to test the vulnerabilities and make sure they were for real. What they did next, however, raised the ire of Microsoft and others within the software industry.
In addition to sending information about the vulnerabilities to Microsoft, GreyMagic published information on their public Web site about the vulnerabilities along with code showing how the vulnerabilities could be exploited. They also sent e-mail announcing their discovery to a variety of public Web sites frequented by computer security experts and computer hackers.
X-Force™ Vulnerability Disclosure Guidelines
(Revised November 18, 2002) (PDF) 6 pgs
The following X-Force Disclosure Guidelines communicate X-Force policies and procedures
concerning the disclosure of vulnerability information to third-party vendors and the general
public. These standards provide a careful balance between sometimes conflicting interests and
are intended to be as reasonable and fair as possible to all parties involved.
Responsible Disclosure by Corporate Fiat
The new Organization for Internet Safety aims to make vulnerability disclosure more responsible. It's a good idea, but is the group too corporate to pull it off?
By Jon Lasser Oct 30, 2002
But I believe that it's time for the security community to develop a broadly supported model for disclosing security vulnerabilities. This model should ultimately result in full disclosure of every security hole in every application. Just not all at once.
Legal Framework Needed for Vulnerability
Disclosure Liability
Jane Winn ; Secure Business Quarterly: Vol 2 Issue Three Third Quarter 2002 an @stake®
publication. (PDF) 3 pgs
If the disciplines of computer security theory and practice are now enjoying a post-September 11
Renaissance, the discipline of computer security law remains mired in the Dark Ages.
Primum Non Nocere
Dennis Devlin ; Secure Business Quarterly: Vol 2 Issue Three Third Quarter 2002 an @stake®
publication. (PDF) 5 pgs
Responsible vulnerability disclosure should avoid making an already bad situation any worse. The
guiding principle should be to create methods of disclosing the appropriate vulnerability
information, to the appropriate people, at the appropriate times, and through the appropriate
channels.
Responsible Vulnerability Disclosure:
Challenges for Vendors Whose Products Are Infrastructural
Jim Duncan ; Secure Business Quarterly: Vol 2 Issue Three Third Quarter 2002 an @stake®
publication. (PDF) 5 pgs
We are all charged with protecting the critical infrastructure; if we fail to act accordingly, we
become part of the problem rather than part of the solution.
Responsible Vulnerability Handling: "A Hard
Problem"
Jeffrey Schiller ; Secure Business Quarterly: Vol 2 Issue Three Third Quarter 2002 an @stake®
publication. (PDF) 5 pgs
What to do has been a source of debate in the computer security community for many years. Some
believe that telling the author is the only responsible thing to do. On the other extreme are
those who believe that full public disclosure, complete with an exploitation program, is an
appropriate response. The reality is somewhere in between.
What is Vulnerability Disclosure?
Dr. Daniel E. Geer, Jr. ; Secure Business Quarterly: Vol 2 Issue Three Third Quarter 2002 an
@stake® publication. (PDF) 3 pgs
You know of a risk that is at once otherwise unknown yet avoidable, but you're not either the
source of the risk or the one at risk. You cannot tell anyone the facts without handing them
responsibility at the same time. Whom do you tell?
HP, Bug-Hunters Declare Truce
Analysis: The story behind SnoSoft's pitch, the extortion charges, and the DMCA threat
Kim Zetter, special to PCWorld.com August 09, 2002
The relationship between software vendors and the bug hunters who sportingly seek out flaws in their products is often tenuous. Throw in some clashing egos, a perception of greed, and some poorly phrased communications and that relationship is likely to snap.
That's apparently what happened here last week during the BlackHat and Defcon security conferences when Hewlett-Packard and Secure Network Operations (SnoSoft) squared off over alleged bugs in an HP product. HP even accused SnoSoft of violating the Digital Millennium Copyright Act when someone associated with the researchers posted code that could be used to exploit one of the vulnerabilities.
Show us the bugs - users want full disclosure
By John Leyden Posted: 08/07/2002
End-users overwhelmingly support the full disclosure of security vulnerabilities, according to a recent survey by analysts Hurwitz Group, which demonstrates widespread frustration about vendor responsiveness to security issues.
Government Against Full Disclosure of Vulnerabilities
By Thor Olavsrud August 1, 2002
The government is urging "white hat" hackers to search for security flaws in software, but also wants them to only pass information about those flaws on to software vendors and the government, not to the rest of the security community as is common practice today.
Symantec's SecurityFocus buyout met with pessimism
By Thomas C Greene in Washington Posted: 22/07/2002
There's been considerable discussion this weekend of the recent sale of SecurityFocus to mega-corporation Symantec for a sweet $75 million. At issue in particular is SF's BugTraq mailing list, which has for years been the most popular full-disclosure vulnerability list going.
Should you keep security holes secret?
By Michael S. Mimoso, News Editor 10 Jul 2002, SearchSecurity
IT has had its fill of buggy software, and it's not going to wait 30 days any more to disclose what it knows
Irresponsible Disclosure
Internet Security Systems violated community standards and common sense with its surprise Apache bug announcement.
By Jon Lasser Jun 26, 2002
The Apache security hole reported by ISS last week ends one of the most remarkable streaks in computer security. The last major Apache security holes were reported in January 1998. Four and a half years without a serious vulnerability in so widely used an application is an incredible record, one for which the Apache team should be commended.
The Apache vulnerability, full disclosure, and monocultures
June 2002
Full disclosure of security vulnerabilities is (usually) seen as a good thing in the free software community. Freedom, with regard to software, includes the freedom to know about (and fix) problems. And, of course, full disclosure is a powerful tool for forcing a software maintainer to release a fix - most of the time. As a general rule, nobody is more secure when the crackers are the only ones to know about security problems.
Apache admins screwed by premature vuln report
By Thomas C Greene in Washington Posted: 18/06/2002
There's a controversy brewing over the announcement of a new Apache vulnerability similar to the chunked encoding flaws in Microsoft IIS, which we reported here and here.
On Monday, Internet Security Systems (ISS) posted their discovery to the BugTraq mailing list, without knowing the full extent of the flaw, and without giving Apache.org time to investigate and develop a patch or even propose a workaround. To sugar the pill ISS had developed its own patch, which Apache later said doesn't address all the issues. Another point in the ISS advisory which Apache disputes is a claim that only installations on Windows are vulnerable.
Patch or No, Flaws to Go Public
By Dennis Fisher May 28, 2002
A security researcher well-known for finding dozens of vulnerabilities in all manner of software products announced Monday that he will no longer automatically wait for a vendor to patch a flaw before he notifies the general public of the problem.
Setback for security through obscurity scheme
By John Leyden Posted: 19/03/2002
A proposal on the "responsible disclosure of security vulnerabilities" has been withdrawn from consideration by the Internet Engineering Task Force (IETF), after criticism that the issue was too political to be decided by the Net's prime technical standards body.
Task force turns down security proposal
James Middleton , 19-03-2002
The Internet Engineering Task Force (IETF) yesterday rejected a proposal submitted by leading security experts on standard procedures for the reporting and fixing of security vulnerabilities.
The internet watchdog said the paper, originally submitted at the end of last month, was "inappropriate".
'Responsible Disclosure' Draft Could Have Legal Muscle
A proposed Internet standard would dictate how researchers report and vendors close security vulnerabilities. Ignoring it could be risky for either side.
By Mark Rasch Mar 11, 2002
A proposal recently submitted for comment to the Internet Engineering Task Force by Steve Christey of MITRE and Chris Wysopal of @Stake would create an official standard for reporting security vulnerabilities to vendors, and for vendors to respond to any such reports. It's worth reading, because if it becomes an official Internet standard, called an "RFC", it could expose those who fail to adhere to it to legal liability for negligence or defamation.
Security Proposal Renews Old Debate
By Dennis Fisher March 4, 2002
A proposal for a new process for disclosing security vulnerabilities has reignited the old debate over how flaws should be published and whether there's any way to regulate the process.
The document, titled "Responsible Disclosure Process," outlines a detailed, step-by-step process for everyone involved in the discovery and reporting of vulnerabilities -including researchers, vendors and third-party security experts.
Written by Chris Wysopal, director of research and development at @Stake Inc., in Cambridge, Mass., and Steve Christey, lead information security engineer at The Mitre Corp., based in Bedford, Mass., the document was forwarded to the Internet Engineering Task Force last week.
Security Through Obscurity Considered Dangerous Broken Link
Steven M. Bellovin and Randy Bush 2002.02.28 INTERNET-DRAFT
Hiding security vulnerabilities in algorithms, software, and/or
hardware decreases the likelihood they will be repaired and increases
the likelihood that they can and will be exploited by evil-doers.
Discouraging or outlawing discussion of weaknesses and
vulnerabilities is extremely dangerous and deleterious to the
security of computer systems, the network, and its citizens.
Proposal Calls for Quick Response to Flaw Discoveries
By Dennis Fisher February 25, 2002
A proposal for a new process for disclosing security vulnerabilities has reignited the old debate over how flaws should be published and whether there's any way to actually regulate the process.
The document, titled "Responsible Disclosure Process," outlines a detailed, step-by-step process for everyone involved in the discovery and reporting of vulnerabilities - including researchers, vendors and third-party security experts.
Written by Chris Wysopal, director of research and development at @stake Inc. in Cambridge, Mass., and Steve Christey, lead information security engineer at The Mitre Corp., based in Bedford, Mass., the document was forwarded to the Internet Engineering Task Force last week.
Internet Draft on Vulnerability Disclosures
Posted by michael on Slashdot February 21, 2002
Cowboy71 writes: "An interesting posting on Bugtraq by Stephen Christie announcing the release for comment of an internet-draft "Responsible Disclosure Process" document, prepared by himself and Chris Wysopal of @stake. You can view the full paper at the IETF site."
Responsible Vulnerability Disclosure Process Broken link
Steve Christey and Chris Wysopal February 2002 RFC
Windows EXPloitable
Securius Newsletter Vol 3.01 — Vol. 3, #01 2002-1-22
Imagine this dilemma: You know that the company you work for is shipping a popular product that contains a dangerous problem. There are hundreds of millions of dollars of revenue on the line and only a handful of people outside the company who know about the problem. Do you inform your customers about the problem -- thereby letting them make an informed decision about whether to continue to use a dangerous product -- or do you keep them in the dark until you have a fix?
Con: Trust, but verify, Microsoft's pledge
By Bruce Schneier January 18, 2002
Microsoft knows that it doesn't have a future unless it can convince the public that Windows XP and .Net are secure, safe and trustworthy. Keeping vulnerabilities secret will only reduce the pressure on Microsoft, allowing them to revert to pretending that they're secure when they're really not.
Microsoft, terrorism, and computer security
By Oxblood Ruffin Posted: 14/12/2001
At the heart of the security debate are two competing approaches: 'security through obscurity,' in which it's hoped that concealing an exploitable defect will prevent exploitation, and 'full disclosure,' which works on the premise that forewarned is forearmed, and which most professionals now prefer.
The disclosure debate rages
By Michael S. Mimoso, News Editor 10 Dec 2001, searchSecurity
Software vulnerabilities and security incidents are certainly no chicken and egg riddle: You can't have an incident without a software vulnerability.
Reporting software bugs/holes/flaws/vulnerabilities and the incidents that result, however, is not as cut-and-dried.
Full Disclosure
by Bruce Schneier Crypto-Gram: November 15, 2001
Microsoft is leading the charge to restrict the free flow of computer security vulnerabilities. Last month Scott Culp, manager of the security response center at Microsoft, published an essay describing the current practice of publishing security vulnerabilities to be "information anarchy." He claimed that we'd all be a lot safer if researchers would keep details about vulnerabilities to themselves, and stop arming hackers with offensive tools. Last week, at Microsoft's Trusted Computing Forum, Culp announced a new coalition to put these ideas into practice.
This is the classic "bug secrecy vs. full disclosure" debate. I've written about it previously in Crypto-Gram; others have written about it as well. It's a complicated issue with subtle implications all over computer security, and it's one worth discussing again.
Bug secrecy vs. full disclosure
By Bruce Schneier, Special to ZDNet November 13, 2001
Microsoft is leading the charge to restrict the free flow of computer-security vulnerabilities.
Last month Scott Culp, manager of the security response center at Microsoft, published an essay describing the current practice of publishing security vulnerabilities to be "information anarchy." He claimed that we'd all be a lot safer if researchers would keep details about vulnerabilities to themselves, and stop arming hackers with offensive tools. Last week, at Microsoft's Trusted Computing Forum, Culp announced a new coalition to put these ideas into practice.
Schneier On Full Disclosure
Posted by Hemos on Slashdot November 13, 2001
Bruce let me know that he's written a piece on ZDNet (original home of the for the Window of Exposure idea is on Counterpane?) about the problems of not following full disclosure. Very well written and does a great job of summarizing why full disclosure works. The original piece from Culp @ Microsoft is also available, along with the PowerPoint that they did.
The Case For Full Disclosure In The Linux Changelog
Posted by timothy on Slashdot November 11, 2001
titurel writes: "This article on SecurityFocus takes up some interesting thoughts about how Alan Cox's choice not to unveil securitychanges in the kernel changelog could affect other developers." And Jon Lasser is no security dummy -- Along with Jaye Beale, he's one of the guys behind Bastille Linux, and the author of the excellent Think Unix.
Microsoft Reveals Anti-Disclosure Plan
Five computer security firms join Microsoft to set an official standard for limiting disclosure of software security holes
By Kevin Poulsen Nov 9, 2001
Microsoft and five major computer security companies rounded up the three-day Trusted Computing Forum on Thursday by formally announcing a coalition against full disclosure of computer vulnerability information, ending a week of intense speculation, and immediately sparking controversy.
Proposal - The Responsible Disclosure Forum
Written by Russ Cooper - 11/8/2001
Here's something I have floated over the past year with a wide variety of people, including Microsoft. I offer it up here for focused debate. I've numbered the paragraphs so that people responding can be specific as to what aspect they are discussing.
Responsible Disclosure Forum - Objective
Via the Responsible Disclosure Forum the discussion about Full Disclosure will be laid to rest, satisfactorily to the moderates of both sides of the discussion. You either participate in the Responsible Disclosure Forum, or you're a Black Hat bent on being malicious, end of story. Too much money, too many individuals, and too much of the world's communication rely on Responsible Disclosure for it to be continued to be seen as a discussion worth debating. In the Medical Profession, and other similar research environments, nothing is published before its been vetted by peers and includes extensive research on impact and ethical issues. The same must now be said of security vulnerability discussions, and the goal of the Responsible Disclosure Forum is to make that a reality.
Keep Security Censorship Away From Linux
Opponents of vulnerability disclosure may have a surprise ally in Linux's second-in-command
By Jon Lasser Nov 6 2001
October was a bad month for proponents of full disclosure. First, Microsoft's Scott Culp argued in an essay that security researchers shouldn't reveal the nature of security holes in software. Then Culp may have found an unexpected ally in his war against full disclosure: Linux's second-in-command, Alan Cox.
Cox's decision to delete security-related material from the Linux kernel changelog seems almost to honor Culp's request that we suppress information useful to attackers.
While at least some of the security changes made in the prerelease of the 2.2.20 Linux kernel have already been discussed elsewhere, Cox claims that describing these changes might be in violation of the same anti-circumvention provisions of the Digital Millennium Copyright Act (DMCA) used to prosecute Russian programmer Dmitri Sklyarov, and cited by Professor Felten in his initial decision not to publish a paper describing weaknesses in SDMI.
On smaller or more tightly-controlled networks, it may be true that full disclosure does not directly serve the needs of system administrators. But network administrators at medium and large sites must have access to exploit code in order to ensure the security of their networks. Unless one administrator has access to every single device on his or her network, there are times when the only way to test for a vulnerability is to attempt an exploit against a server.
MS to force IT-security censorship
Creating, then throttling, security 'partners'
By Thomas C. Greene, The Register Nov 2 2001
We all know how Microsoft likes to bully its many 'partners', so it comes as no surprise that the Beast has decided to apply its partnership muscle to silence the software and network security research community.
The company is currently shopping a 'security partnership agreement', which would open up reams of MS vulnerability data to those firms which capitulate to its censorship demands while leaving all others out in the cold, The Register has learned.
Keeping Security Issues in the Open
Microsoft's security manager is arguing, in effect, that security issues should be kept secret - and out of the flow of publicly available information.
Chris Davies October 26, 2001
The manager of the security response center at Microsoft (Nasdaq: MSFT), Scott Culp, apparently wants to keep security issues in a box -- and out of the hands of those affected by them.
Security in an Open Electronic Society
Microsoft's argument against 'information anarchy' is as self-serving as it is illogical.
By Elias Levy Oct 21, 2001
A recurring argument in the computer security world is that clamping down on the dissemination of information about vulnerabilities, and tools that exploit them, will mitigate everyone's risk. Last week, one proponent of this argument, Scott Culp, manager of Microsoft's security response center, coined the term "information anarchy" to describe the current situation, comparing it with yelling "fire" in a crowded movie house.
Microsoft: Stop leaking bug code!
By Robert Lemos, ZDNN October 17, 2001
Microsoft, whose software has been at the center of several recent high-profile security incidents, has decided to turn up the heat on those the company considers at least partially responsible: security firms and hackers who release sample programs to exploit software flaws.
This week, Scott Culp, manager for Microsoft's security response center, published an essay on the company's site decrying the information and example code released by some companies and independent security consultants as "information anarchy."
Full Disclosure: How Much Security Info Is Too Much?
In publicizing the details of how a given security hole is exploited, are virus fighters simply providing aid and comfort to the enemy?
Jay Lyman October 02, 2001
The debate over how much detail to release on software security gaps and when to go public with potentially sensitive security information has experts looking for a middle ground, wherein systems can be secured without helping hackers.
It’s Time to End Information Anarchy
By Scott Culp October 2001
Code Red. Lion. Sadmind. Ramen. Nimda. In the past year, computer worms with these names have attacked computer networks around the world, causing billions of dollars of damage. They paralyzed computer networks, destroyed data, and in some cases left infected computers vulnerable to future attacks. The people who wrote them have been rightly condemned as criminals. But they needed help to devastate our networks. And we in the security community gave it to them.
Three Minutes With Security Expert Bruce Schneier
Security expert pushes full disclosure, forcing vendors to admit and fix bugs quickly.
Kim Zetter, PCWorld.com September 28, 2001
PCW: Is full disclosure beneficial or harmful to security?
Schneier: The full-disclosure movement appeared because companies were ignoring the problems with security holes or lying about them. Security professionals and amateurs would find a security flaw, alert the company, and the company would threaten them with a lawsuit and not fix the problem. Or they would send the vulnerability to an organization like CERT [the Computer Emergency Response Team at Carnegie Mellon University], which would sit on it for five months.
So the full-disclosure movement was formed out of frustration. And by God it works. If you told Microsoft there was a problem a bunch of years ago, they would have told you to shut up. Nowadays they know they better fix it fast because it's going to be in the newspaper next week.
In some ways full disclosure helps the bad guys, but it also helps the good guys. So it's double-edged. I think if we said we're no longer going to do full disclosure, the companies would go back to paying lip service and not care about it. So you need it to keep the pressure on. Right now what the community has settled on is alert the company, give them reasonable notice, and then announce the vulnerability. And that seems to be working.
Coalition condemns full disclosure
James Middleton , 09-11-2001
Microsoft and five big name security firms have put the boot into the full disclosure argument by announcing a coalition to limit the disclosure of vulnerability information.
At the Trusted Computing Forum held in California this week Microsoft, along with ISS, @stake, Bindview, Foundstone and Guardent, revealed a formal coalition to push for a standard policy of limiting public disclosure of security vulnerabilities.
The as yet unnamed organisation plans to draft a international standards proposal, submitted as a Request For Comments to the Internet Engineering Task Force (IETF).
Motives of Code Red Bug Hunters Questioned
Bug hunters say they're doing a service by publicizing vulnerabilities; critics say otherwise.
Kim Zetter, PCWorld.com September 05, 2001
Code Red's astonishing success at infecting computers has reignited a fierce debate about full disclosure--the practice of publishing information about security holes. The discussion has even led some to question the motives of those who discovered the hole in the Microsoft software that Code Red exploited.
Industry Fears the Red Pill
The security community must choose between the red pill of full disclosure or the blue pill of security through obscurity.
By Richard Forno August 29, 2001
Full disclosure is a security philosophy based on the principle that the details of security vulnerabilities should be made available to everyone so that all users - not just vendors or potential intruders - can benefit from knowledge of potential weaknesses. By making the information public, the security community forces the vendor to be accountable for any vulnerabilities. If weaknesses are discovered, vendors can be pressured into providing security fixes quickly. Furthermore, because the information is common knowledge, all members of the community can take the appropriate steps to protect themselves if they are employing the software in question.
Full Disclosure is a necessary evil
Revealing the details of security holes gives everyone a chance to close them.
By Elias Levy Aug 16, 2001
Lately there has been renewed debate over the practice of releasing detailed information on newly-discovered software vulnerabilities, with critics charging that 'full disclosure', as it is normally called, enables malicious users to break into systems, or to create viruses and worms.
Can we afford full disclosure of security holes?
Richard M. Smith Bugtraq Posting August 10, 2001
Full Disclosure
Are security software vendors trying to keep systems safe from threats such as Code Red, or are they more worried about self-promotion?
By George V. Hulme Aug. 6, 2001
Marc Maiffret won't be mistaken for one of the heavyweights of the IT industry. But there was his name last week, right alongside Microsoft's, in the debate over their roles in one of the most serious threats yet to Internet security--a malicious computer program called Code Red.
Maiffret is learning that with the spotlight comes a certain amount of heat. "I just got finished talking with the FBI," he says from his office in Aliso Viejo, Calif., where he goes by the title of chief hacking officer for security software company eEye Digital Security. Maiffret's company discovered the flaw in Microsoft's server software, Internet Information Services, that Code Red exploited. So, as the FBI talked to Maiffret to learn about Code Red's origins, his peers in the IT industry were questioning why eEye published information about the flaw that was so detailed it could have made a hacker's task easier.
Introducing constructive vulnerability disclosures
Marko Laakso, Ari Takanen, Juha Röning June 17, 2001 (PDF) 8 pgs
Product flaws that compromise information security emerge constantly, and a vivid debate is taking place on how these vulnerabilities should be handled. A partial disclosure concept, constructive disclosures, was introduced as an alternative to full disclosures and as a safety-net against reoccurring vulnerabilities of a similar kind. The proposed model was executed in a multi-vendor, multi-vulnerability case involving WAP gateway products. A complicated vulnerability case was successfully handled, with positive feedback. This result promotes the seeking of solid engineering practices that will take the vulnerability process beyond an art form.
Senator Wants to Aid Cyber Security by Secrecy
By Andy Sullivan WASHINGTON (Reuters) May 07, 2001
A key U.S lawmaker said Monday that he was planning to introduce legislation that would shield information about computer networks from public inquiry to encourage cooperative efforts toward boosting cyber security.
An informal analysis of vendor acknowledgement of vulnerabilities
Steve Christey coley@mitre.org Barbara Pease bjp@mitre.org March 11, 2001
Russian hackers play dirty pool with Auktion advisory
(02/15/2001)
Every once in a while a bughunter does something that is, well, downright nasty, in the name of improving general security. Usually this takes the form of publishing code that could potentially wreak havoc on innocent systems. In a recent Bugtraq posting, Russian defacement posse UkR not only publicized a vulnerability and released the exploit, but also provided a couple of handy-dandy URLs on which curious parties could test the exploit.
How quickly should security flaws be made public?
By Dennis Fisher, eWEEK February 9, 2001
For as long as computers have been in use, information about the security (or lack thereof) of the machines themselves and the software they run has been doled out in tantalizingly tiny bits on a need-to-know basis.
How do you justify full disclosure? Broken Link
by justin case 28 Jan 2001)
This are just some random thoughts about the whole blackhat/greyhat/whitehatdiscussion. I myself am noone interesting.. If you searched the web formy real name or nick you'd find out that I've released some exploits to BQ,am member of some non-profit security groups and have often made anidiot of myself by talking about stuff i didn't really understand.So with the readership i can expect, im pretty much just like that otherguy you know from irc.
Microsoft miffed at Bulgarian bug buster
By John Leyden, The Register January 19, 2001
Redmond says hasty disclosure, not buggy software, puts customers at risk.
CURMUDGEON'S CORNER: Full Disclosure? Full Complicity!
Deconstructing the myths behind the full-disclosure debate.
By Jay Heiser Information Security Magazine CURMUDGEON'S CORNER Column January 2001
The term "full disclosure" is marvelously ambiguous, and therein lies much of the problem. It essentially means to "widely disseminate as much information about system vulnerabilities and attack tools as possible so that potential victims are as knowledgeable as those who attack them." Admittedly, this concept has a certain appeal. But where does this "information" to disseminate come from?
The Full Disclosure of Computer Security Vulnerabilities - An Examination of the Debate
By Tami Goens An Abbreviated Version of the Undergraduate Distinction Project BSBA 2001, The Ohio State University
BugTraq, a popular mailing list now hosted by securityfocus.com, was founded in 1993 to provide a forum for open publication of computer and network security vulnerabilities. Due primarily to the rapid pace of software development and the proliferation of the Internet, there has been a shift away from keeping computer security vulnerabilities private. Prior to mailing lists such as BugTraq, information on computer and network security vulnerabilities remained in the hands of a few, primarily computer security researchers and the underground criminal element. Retaliation against this form of private information led many individuals working in computer security to adopt what has become known as full disclosure. This practice of publicly disclosing computer security vulnerabilities fueled a heated debate, as there are both positive and negative consequences of releasing such information to the masses.
The goal of this distinction project was to determine the attitudes about disclosure practices in the computer security community regarding issues surrounding full disclosure. Two hypotheses were tested. First, a majority of those in the computer security field support the full disclosure model of disseminating vulnerability information and second, attitudes on the full disclosure debate will vary across participation in different computer security circles. In order to test these hypotheses, opinions from users of full disclosure information and computer security practitioners were solicited using an on-line survey. Survey links were distributed through the FBI-coordinated computer security organization, InfraGard, the Information Systems Security Association, and the popular full disclosure mailing list, BugTraq.
A Note on Security Disclosures
by Brian Martin 12/2000 (PDF) 5 pgs
Full Disclosure
Brian Deline November 28, 2000
What is full disclosure? Full disclosure refers to the computer security concept that releasing complete details of a computer vulnerability to the public is the best way to get vendors to fix security problems.
"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, they (sic) 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.
CERT Narrows Window for Security Holes
Advisory service will report all flaws within 45 days
By Jaikumar Vijayan (October 16, 2000)
Users who support public disclosure of security vulnerabilities got an unexpected boost recently.
Carnegie Mellon University's CERT Coordination Center security advisory service last week instituted a new policy under which it plans to publicly disclose all software flaws and vulnerabilities 45 days after they're first reported to the organization.
The Pros and Cons of Posting Vulnerabilities
Announcing security holes alerts managers but also hints at new exploits.
Rik Farrow Network Magazine 10/05/00
CERT And Vulnerability Disclosure
Posted by CmdrTaco on Slashdot October 08, 2000
Carnage4Life writes "In a radical departure from it's previous stance of security through obscurity, the Computer Emergency Response Team, CERT, has stated that it will fully disclose all vulnerabilities in software that come to it's notice 45 days after the fact whether or not companies have provided a fix. The change of policy can be found at the CERT site and there is also a story on C|net. The change is not a complete embrace of full disclosure because CERT will not release exploits as some other software security watchdogs do."
CERT to disclose software flaws Broken Link
By Robert Lemos, ZDNet News October 07 2000
The security incident response center will give software companies 45 days to fix security flaws, joining the trend toward open discussion of vulnerabilities.
It may herald the end of a fight that has inflamed the security community for more than a decade: The Computer Emergency Response Team, or CERT, has endorsed a policy of open flaws in software that could affect security.
The change, announced this week, signals that traditionally conservative organizations are now leaning towards publicly releasing information about software vulnerabilities rather than remaining silent.
Three months ago, Macus Ranum, a well-known security expert and founder of the intrusion-detection software maker Network Flight Recorder, strongly urged a gathering of network professionals to keep secret any security holes found in Internet software and stop creating tools to exploit the holes.
Elias Levy, chief technology officer for industry information site SecurityFocus.com.
The CERT® Coordination Center Vulnerability Disclosure Policy
Effective October 9, 2000, the CERT Coordination Center will follow a new policy with respect to the disclosure of vulnerability information. All vulnerabilities reported to the CERT/CC will be disclosed to the public 45 days after the initial report, regardless of the existence or availability of patches or workarounds from affected vendors. Extenuating circumstances, such as active exploitation, threats of an especially serious (or trivial) nature, or situations that require changes to an established standard may result in earlier or later disclosure. Disclosures made by the CERT/CC will include credit to the reporter unless otherwise requested by the reporter. We will apprise any affected vendors of our publication plans, and negotiate alternate publication schedules with the affected vendors when required.
Full Disclosure is bogus
Marcus J. Ranum
Full Disclosure and the Window of Exposure
by Bruce Schneier Crypto-Gram: September 15, 2000
Every season yields a bumper crop of computer security stories: break-ins, new vulnerabilities, new products. But this season has also given us a crop of stories about computer security philosophy. There has been a resurgence in opposition to the full disclosure movement: the theory that states that publishing vulnerabilities is the best way to fix them. In response, defenders of the movement have published their rebuttals. And even more experts have weighed in with opinions on the DeCSS case, where a New York judge ruled that distributing an attack tool is illegal.
Do security holes demand full disclosure? Broken Link
By Weld Pond, @Stake, Special to ZDNet News August 16, 2000
Weld Pond writes "Every once in a while we need to step back and reassess the effects of the release of detailed security information and tools on the real world. And that's what happened recently at DEF CON 8.0, the annual hacking conference held in Las Vegas." Mr. Pond offers a very good perspective. While I for one am 100% for full disclosure I can see both sides of the argument.
Debate erupts over disclosure of software security holes
by Ann Harrison July 31, 2000
In a contentious keynote speech that created an uproar at the Black Hat Briefings security conference here in Las Vegas Wednesday, security researcher Marcus Ranum charged that the full disclosure of software vulnerabilities isn't improving computer security. Instead, Ranum said, it only encourages attacks by what he called "armies of script kiddies."
Silence the best security policy
Should security holes be hushed up?
By Robert Lemos, ZDNN July 26, 2000
Long controversial, the policy of disclosing software vulnerabilities to the public was subject to open attack in a Wednesday keynote at the Black Hat Security Conference.
Marcus Ranum, chief technology officer for intrusion detection software maker Network Flight Recorder Inc., used hard language to say that security can't be improved unless "gray hat" hackers stop disclosing security holes to the public and stop creating tools for so-called "script kiddies" to exploit the holes.
Full Disclosure and Open Source
Marcus Ranum Keynote Speaker Black Hat Briefings Las vegas July 2000
Anatomy of a Security Nightmare or How Full Disclosure Got S&P To Secure Their Network
Stephen J. Friedl
Since at least December of 1999 -- probably much longer -- and until very recently, the Standard and Poors (S&P) ComStock data network has been open to allow essentially unlimited access between the internal networks of unrelated subscribers. This is a security nightmare of enormous proportions, but even more unbelievable is how S&P utterly ignored repeated and persistent notification of this vulnerability.
This is the story of how two unrelated security consultants tried, and ultimately succeeded, in getting this addressed only with the aid of very full disclosure.
Full Disclosure
To disclose or not to disclose? When it comes to vulnerabilities and viruses, that is the question.
BY M.E. Kabay Information Security Magazine May 2000
One of the ongoing debates in infosecurity concerns how we should handle known vulnerabilities and dangerous viruses. Should we publish full details, conceal some details, or suppress publication entirely until patches or updates are available?
Weld Pond on Full Disclosure
The well-known hacker explains why he supports the policy of publicizing security holes.
Posted February 25, 2000
The Future of Vulnerability Disclosure?
by Jeremy Rauch jrauch@securityfocus.com 11/1999
Jeremy Rauch is a founder of SecurityFocus.com, a Web site that disseminates security information to the public and maintains a number of popular forums and mailing lists, including the Incidents and Bugtraq mailing lists.
The Vulnerability Process: a tiger team approach to resolving vulnerability cases
Laakso M. Takanen A. Röning J. June 13 1999 (PDF) 24 pgs
Ten General Security Rules - Rule 2: Full Disclosure of Bugs and Holes Benefits Security
Excerpt from Unix System Security Tools by Seth T. Ross Copyright © 1999
The Estimate of a Virus
Here is how it goes... I will use this recent AIM exploit as an example
for some of the attacks on the Full Disclosure movement.
It is a big hole on over a 100 million systems. A temporary fix was
given for users to keep unknown users from contacting them on their
buddy list by the bug finders. This - if not the default security setting,
anyway - should be. There is no reason you need to be contacted and
put on your buddy list people you do not know.
Full Disclosure: Effective or Excuse? Broken Link
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.
By Brian Martin
The world of computer security has developed a wicked game of politically correct cat-and-mouse. This game is played out through security professionals contacting software vendors to report security vulnerabilities that affect a large portion of their customers. Like a large percentage of professional interaction, the supposed need to act within certain guidelines or be politically correct (PC) comes into play. The side-affect to this game comes in the form of slower patches and upgrades to address the problem.
Full Disclosure of Vulnerabilities - pros/cons and fake arguments
Alt Source
Arne Vidstrom, arne.vidstrom@ntsecurity.nu
Should the complete details of security vulnerabilities be made public or not? Not only do we need to understand the true pros and cons, but we also need to understand the "fake arguments" - the arguments people bring forth to serve some other purpose than making the "truely right" decision. This paper will try to point out all these things, to aid in building a more complete picture of the full disclosure concept.
Full Disclosure Policy (RFPolicy) v2.0
This policy states the 'guidelines' that an individual intends to follow. You basically have 5 days (read below for the definitions and semantics of what is considered a 'day') to return contact to the individual, and must keep in contact with them *at least* every 5 days. Failure to do so will discourage them from working with you and encourage them to publicly disclose the security problem.
This policy is not set in stone--in fact, it is encouraged that all parties regularly communicate with each during the process, adjusting as situations arise.
The Pro's and Con's of Full Disclosure in Computer Security
Richard M. Smith Internet Security and Privacy Consultant rms@ComputerBytesMan.Com (PPT)
Vulnerability disclosure publications and discussion tracking
Updated Regularly
A long and vivid debate for and against different vulnerability disclosure models is still taking place. Sources that collect all these valuable arguments are scarce. This document acts as a place-holder for related contributions that we are aware of. Paper, articles and more informal documents are grouped based on the type of publication. We hope that these links are useful to anyone familiarising themselves with the scene or planning further contributions.
Anti Security :: save a bug, save a life
The purpose of this movement is to encourage a new policy of anti-disclosure among the computer and network security communities. The goal is not to ultimately discourage the publication of all security-related news and developments, but rather, to stop the disclosure of all unknown or non-public exploits and vulnerabilities. In essence, this would put a stop to the publication of all private materials that could allow script kiddies from compromising systems via unknown methods.
Disclaimer:
This bibliography is compiled and maintained by Paul Clark, Systems Librarian at the Wilderness Coast Public Libraries and does not necessarily reflect the views of the Wilderness Coast Public Libraries. The information on the web sites linked do not necessarily reflect the views of the Wilderness Coast Public Libraries nor are they under their control.
If you know of additional articles please e-mail the links and I will post them here.
Last Updated 8/3/04