by Rik Farrow <rik@spirit.com>
Once upon a time, only the 'black hats', and a few self-selected 'white hats', had easy access to security vulnerability information. The 'black hats', often called hackers (although I do not want to get into any debates about the correct use of that term), could use their knowledge to break-into computers at will. Systems were rarely patched to fix these problems, as most system administrators remained blissfully unaware of the issues. And the good guy insiders were unwilling to share this information. But things have changed.
On a single day, information and exploits for over twenty vulnerabilities were posted to Bugtraq, a full disclosure mailing list, as well as six postings from vendors with information about patching these and other vulnerabilities. August 2 was an unusual day only in magnitude, as new vulnerabilities appear daily, and vendor notices about patches appear somewhat less frequently. But vendors in general have done a better job at patching security vulnerabilities than they did back in the old days, when security information was hoarded.
Today, there are appeals to put the genie back into the bottle. That is, to stop the publishing of new vulnerabilities. There is even a proposed law that would make some forms of vulnerability testing illegal in the US. Not that this would stop much of the research in security testing, which happens outside of the US. Let's take a look at how things were before full disclosure, as well as what was posted on that extraordinary summer day.
Before we can even consider whether full disclosure is good or bad, let's take a stroll down memory lane. The release of the Internet Worm shocked people, even though the vulnerabilities used by Robert Morris were well known--by a selected few. Morris had worked for the NSA as a summer intern, where he was explosed to some of the vulnerabilities he would write into his worm. He also learned about the concept of the buffer overflow attack, found a weakness in a popular server, and crafted his own exploit. That portion of the Worm was the most original exploit (all others were known problems), but not the most effective means the Worm used to break in.
After the attack, the Worm code was disassembled, but the results were not published, except in broad descriptions, for many years. There were good reasons for this. After the Worm, there were several copycat worms, none as successful as the orignal. The Computer Emergency Response Team was created to help disseminate information about new attacks, but very quickly ran into trouble. Early CERT advisories contained enough information in some cases to create exploits, so instead of reducing attacks, advisories were sometimes followed by an increase in the frequency of the very attacks warned about in advisories. This quickly lead to CERT producing advisories that were sufficiently vague, so as to not create more trouble.
The cautionary posture resulted in CERT being viewed very unfavorably by the community it was supposed to serve. Early CERT advisories contained enough information to test for the reported vulnerabilities, but the newer, vague, advisories left system administrators feeling that they were almost useless. One of the problems with any security advisory is knowing when your system is vulnerable and must be patched, as sometimes installing a patch will break a critical system that was working 'perfectly' before the patch was installed. The ability to test for vulnerabilities was considered crucial by many experts.
CERT Advisory CA-93:15 provided an excellent example of the problem. This adisory covered three different programs, but referred only to Sun operating systems. However, one of the programs, sendmail, comes from a single code base, so a bug in Sun's version implies a similar problem in the versions used by other vendors. Passionate debates appeared in the Firewalls mailing list, with many calling for more information about the sendmail bug. Scott Chasin, the founder of the Bugtraq full disclosure list, posted a new exploit for sendmail in response to the clamour--but it was not the problem the Sun patches fixed. By accident, Sun had released updates to its software that re-enabled one of the holes used by the Internet Worm (the debug command), and wanted to suggest that Sun customers replace the vulnerable version without telling anyone exactly what was wrong.
Exploiting the debug hole is really simple, so advertising this vulnerability would have had unpleasant consequences. But not divulging the exact issue also had its own consequences, as experts wondered what the real problem was, and sysadmins put off installing new patches on their servers because they didn't know it was important. If CERT had published an explicit advisory, anyone who had installed the vulnerable version of sendmail could easily be hacked, but the advisory was so intentionally vague that it caused more controversy than the correct action--replacing only Sun's version of sendmail.
Today, publishing information about security problems in software has become a standard technique for both hackers and security companies. Both individuals and companies publish to show off their hacking acumen to the world, and hopefully, to create good public relations. Etiquette for publishing security holes has been created as well, with SecurityFocus offering free help in creating advisories via a special email address, and Rain Forest Puppy's (RFP) own policy paper (version 1.1) about when and what to publish. RFP also participated in writing a book, "Hack Proofing Your Network", with a strong focus on learning how to find new vulnerabilities.
With all the emphasis on disclosing new vulnerabilities, it is no wonder that reading a single day's bugtraq has gotten to be like watching a long, drawn out debate, with most being said by the 'attacking' side, and less by the defenders. The digest of a approximately 24 hour period (August 1-2, 2000) contained information about over 20 vulnerabilities, many (but not all) newly reported. It also included six vendor advisories or notes, two applying to vulnerabilities revealed that day.
The first vulnerability reported that day was for ntop, a UNIX tool for remotely monitoring network traffic statistics. The tool can be started so that it provides a Web server interface, allowing anyone with a Web browser to use the tool, but also to browse the host file system. Later that day, the tool's author pointed out that the vulnerability had been patched in version 2, over two months before.
Next, the maintainer of an open source package called mailman announced an updated version that fixes two potential security problems, neither severe. Then, some more information about a remote root exploit involving PAM (pluggable authentication module) console on some Linux versions. The next message explains how to exploit various Solaris systems locally in an elevation of privilege exploit, as well as a simple way to prevent the exploit.
LSD, a Polish group (LSD stands for Last Stage of Delirium), posted several lists of URLs, totalling 17 altogether, mainly for exploits of Silicon Graphics systems (with two Sun exploits included). Most of these exploits were buffer overflows that provide root access, and most working over the network. The Sun exploits were old, but LSD promised that their exploit code offers features not found in other versions of the exploits (Sun had announced patches for both the rpc.ttdbserverd and rpc.cmsd exploits long before).
The next posting added details on how to get the 'new' Linux statd exploit working correctly, and a complaint about Microsoft not patching a 'vulnerability' (Microsoft calls this potential denial of service a feature when used in small subnets, see MS00-047).
Guardent, a new security consultancy, pitched in next with a description of how to exploit Windows 2000. The local exploit permitted a user to act as LocalSystem (as good as root on an NT box) by exploiting a flaw in the manner in which the service control manager (SCM) and named pipes interoperate. Guardent was following proper etiquette, as the announcement of Microsoft's patch (MS-0053) appears next in the lineup.
A few messages later, an advisory from Sun appears. The Sun security advisory recommends patching two files, both providing local elevation of privilege (to root) via the lpset or netpr programs, both via buffer overflows. This is followed by an apology by a company whose employee had implemented, but not published, a virus that would install a patch to a Microsoft Outlook vulnerability. The proposed virus, codenamed Antibody, raised a storm of protest, in that using a virus to patch systems, while an interesting idea, was dangerously flawed in several ways (that it was more likely to break things than fix them being only one of the many criticisms).
CORE, an Argentinian security group, provided the last set of vulnerabilities, this time for NAI's PKI server. CORE was building on a previous announcement by a Jim Stickley from Garrison Technologies Inc. and announced three new vulnerabilities not fixed by NAI. The advisory includes a URL for a new hotfix by NAI for the vulnerabilities (CORE was obviously playing by the rules for full disclose etiquette).
The final two postings were for patches to Netscape and the mailman package (mentioned earlier). The Netscape patch was for a bug in the way certain JPEG files were handled that could produce a buffer overflow. More recently, the Brown Orifice HTTPD server, a Java program, exploits a bug on Netscape Web browsers that uses the Java program to turn your browser into a Web server that can read any file on your system that you can, and display them to remote users.
By now, you may be wondering how in the world anyone keeps up with all of the vulnerabilties that are patched (much less the ones that have been announced and not yet fixed). The answer, sadly, is that most systems are not up-to-date. Microsoft, which, to its credit, has become very responsive to fixing problems, has issued (as of early August) 53 advisories, or almost two per week, so far this year.
UNIX versions, including Linux, have not been immune to security vulnerabilities, with a new WU-FTPD vulnerability for Linux systems drawing a lot of attention in July (the format attack). But the rate of new vulnerabilities is comparatively small for all versions of UNIX. Still, unpatched Linux systems remain the target of choice for attackers looking for vulnerable systems to break into and use. The publishing of working exploits has made this easier to do.
On the one hand, full disclosure has improved the security of system enormously. Instead of vendors pretending that nothing is wrong, or that their customers do not care about security, which was the way things were done several years ago, vendors have become amazingly responsive to posted vulnerabilities. There is nothing like lighting a fire beneath someone's feet to get a quick response.
On the other hand, breaking into systems has never been easier because of all of the information published each day. It is important to keep in mind that much of this information would be published underground if full disclosure is made illegal. Making certain techniques, such as reverse engineering, illegal, will result in the work being published overseas, not in the US.
The true goal is simple to state: to write secure software in the first place. This is easier to say than do, however. One UNIX version, OpenBSD, has made it part of their business plan, and has audited all of the code that they ship for security bugs. Their work helps other UNIX vendors, because they do not hide the problems they find, and other vendors are free to follow suit. Microsoft will continue have a more difficult time, because of their completely different and much larger codebase.
An example CERT advisory with vague descriptions, from their archives: http://www.cert.org/ftp/cert_advisories/CA-93:15.SunOS.and.Solaris.vulnerabilities
Help in contacting vendors and crafting advisories: vulnhelp@securityfocus.com
Rain Forest Puppy's policy paper, with advice about how to craft an
advisory:
http://www.wiretrip.net/rfp/p/doc.asp?id=56&iface=2
Last Stage of Delirium, site winning "Most Vulnerabilties Posted on August 2" award: http://lsd-pl.net/.
The bulletin Microsoft published in response to the Guardent advisory: http://www.microsoft.com/technet/security/bulletin/ms00-053.asp