\documentstyle[doublespace]{article}
\author{David Golombek}
\title{Bugtraq: Security Nightmare or Protector?}
\date{\today}
\begin{document}
\maketitle

\singlespace
\begin{abstract}
Security aficionados and consultants from around the world use the
bugtraq mailing list to exchange information about security holes in
computer applications and operating systems.  Programs using these
holes to obtain increased privileges on a computer are posted
to the list and may be used by anyone reading them, which may include
crackers as well as the system administrators for which the list was originally
intended.  This paper will explore the circumstances in which the
bugtraq mailing list is indeed a powerful security tool, why it works
in these circumstances, and suggest other cases in which the mailing
list may not be the correct forum for discussion.  By comparing and
contrasting bugtraq with many other forums for computer security
discussion, the bugtraq forum will be shown to be an effective and
necessary tool for security administrators.
\end{abstract}
\doublespace

\newpage 
\singlespace
\tableofcontents
\doublespace
\newpage
\section{Introduction}


The bugtraq mailing list is a public forum for the discussion of
security holes in operating systems and applications, primarily
focused on but not restricted to Unix systems.  One of the primary
means of proving the existence of new security holes in a program is
to post a program or script that exploits the purposed security hole
to gain access to files or permissions not normally available to the
given user.  The purpose of posting such exploits is to force
immediate action on the part of the creator of the program to fix the
security compromise, and to warn system administrators to disable the
given program until such a bugfix is available.  However, access to
the bugtraq mailing list is extremely widespread, and thus crackers,
as well as the intended system administrators, have access to these
exploits.

This dissemination of security holes worries many people because there
are many system administrators who do not read bugtraq, and thus a
cracker reading the list may learn of new exploits faster than systems
are able to be updated.  Others argue that by posting the exploits to
bugtraq, faster handling of the bug is ensured.  This paper will
explore the history and usage of bugtraq, then examine many other
security resources and the policies used on them to provide contrast
against bugtraq's policy.  Using these comparisons, it will show that
bugtraq is a useful and necessary tool for system administrators and
security consultants.  

\section{Bugtraq Membership}

The bugtraq mailing list was created by Scott Chasin
(chasin@crimelab.com), with the following charter:
\begin{quote}
This list is for *detailed* discussion of UNIX security holes: what
they are, how to exploit, and what to do to fix them.  This list is
not intended to be about cracking systems or exploiting their
vulnerabilities.  It is about defining, recognizing, and preventing
use of security holes and risks.
\end{quote}
The list has strayed slightly from this original charter, expanding to
include exploits of other operating systems and some policy
discussion, but otherwise has remained fairly constant through a few
changes of moderators.  Aleph One (aleph1@dfw.net) is the current
moderator, not to mention a frequent contributor, and has continued
these same policies quietly.  Membership is hard to accurately judge,
because besides those who post to the list, all membership info is
hidden.  Current list information puts bugtraq at 13,433 subscribers, but this
does not include all the redistribution lists and people who read it
off the numerous archives~\cite{archives}.  The list has a very
international character, with roughly half of the exploits being
posted from outside the United States.


\section{Bugtraq Usage}
\label{usage}

Bugtraq averages about 10 messages a day, including messages forwarded to
the list from other security lists \ref{other-lists}.  This average is
quite impressive given the time it takes to discover and track down a
security hole, then develop a full exploit and explanation.  An
average exploit takes a week to develop, not counting the time it
takes to discover the possible existence of a bug.  Although many
authors submit several exploits a year, others only submit one or
two.  It is the sheer number of people working on exploits that makes
the volume on bugtraq possible.

Exploit messages tend to towards one of two formats, either a brief
description of a new hole followed by an exploit script, or a very
long textual description followed by a comparatively short bit of code
to provide an example.  The first type of message usually indicates a
minor bug, or a particular instance of a well known type of bug.  For
example, buffer overflows have recently been discovered in a wide
variety of programs, where too much data is passed to a program which
doesn't pay attention to how much is being entered, and some of the
inputted data is actually executed.  Every time a new exploit for an
instance of a bug is found, a new exploit needs to be written, and so
this type of mail comprises the majority of the volume on bugtraq.  A
minor variation on this type of message is the vendor or CERT
Advisory, usually restating a hole previously mentioned on bugtraq and
announcing the official patch for the bug, where to retrieve it, and
how to install it.

The second type of message is frequently an announcement of a new
class of bug, or a major design flaw in a large program.  These
messages tend to be much longer than the first type, ranging from five
up to thirty pages, and are packed with information.  New types of
bugs are found when new technologies are announced, or finally become
understood well enough to be fully analyzed.  Major design flaws in
programs can be found at any time during that program's lifetime;
sendmail usually has a major design flaw discovered every six months.
In either case, it is the concept described in the paper that is
usually important, not the exploit, which is just there to demonstrate
the that the concept is valid.

The third type of mail to the bugtraq list are policy messages, be they
about the policy of bugtraq itself, government policy about
cryptography, or new vendor policies with regard to security.
Although not directly topical, these messages are deemed to be of
interest to people who are interested in security, and thus allowed by
the moderator.  Usually these mailings are strictly a news clipping
inserted into an email, with very little editorial comment by the
sender, and followups are usually redirected to other lists.

\section{Contributors}
\label{contributors}

A further exploration into the two main types of exploits leads to
several interesting points about the readers of the mailing list and
the contributors.  Authors of the shorter type of message tend to be
less experienced hackers, or experienced programmers new to the
security field.  A programmer may have worked in industry for many
years and still have no idea about security issues because of the
entirely new mind set that is involved.  The shorter postings usually
are the result of such a person reading an exploit of the second type
(see \ref{usage}) and searching for holes similar to the original one
in other programs, or slight variations on the same bug.  Most of the
recent bugs in Netscape and Internet Explorer are of this type, as are
the long-running stream of buffer-overflow bugs.  Bugs of this type
are often found by exhaustive search methods --- the author will read
of a certain type of security hole, and search all programs on his
system for that hole or a variation on it.  This methodical search is
just as valid as searching for holes via algorithm inspection; neither
method is ``better'', since both are needed to plug all security holes
on a given machine.

Authors of the longer, more innovative exploits tend to be security
experts who spend their whole lives working on such issues.  There are
very few of these (several of them will be mentioned in this
paper), and most make a career out of their security work.  The
exploits these people publish usually involve weeks or months of
research, and are often descriptions of a generic type of bug likely
to be found in many different applications.  One of the prime examples
of this type of message was Hobbit's \underline{CIFS: Common
Insecurities Fail Scrutiny}~\cite{CIFS}.  In this paper, the author
took a protocol specification published by Microsoft and analyzed the
security system involved within it, exposing several severe holes in
the protocol.  His analysis was so comprehensive that Microsoft
subsequently took him to several dinners to ask him more questions and
discuss ways of fixing the weaknesses he had found.  This reaction is
unfortunately all to unusual, see \ref{vendors} for more common
reactions.

\section{Related Sources of Information}
\label{related-sources}

Bugtraq is by no means the only security related mailing list on the
Internet.  However, the approach it takes to security is unique, and
by comparing it to other sources of information, the points where
bugtraq is different become obvious.

\subsection{CERT}
\label{cert-section}

One of the groups most frequently compared to bugtraq is the CERT
group at Carnegie Mellon~\cite{CERT}.  CERT is an actual research
group which has grown out of another group formed by the Defense Advanced
Research Projects Agency shortly after the Internet worm incident.
It's official charter is to
\begin{quote}
Work with the Internet community to facilitate its response to
computer security events involving Internet hosts, to take proactive
steps to raise the community's awareness of computer security issues,
and to conduct research targeted at improving the security of existing
systems.
\end{quote}
To accomplish these goals, CERT tries to act as the official
coordinator for all security work on the Internet.  Unfortunately, it
is woefully understaffed, hampered by poor communications with sysops,
and extremely cautious about possible legal liabilities for it's
work.  CERT publishes official security advisories regarding ``new''
security holes discovered and distributes them very widely.  However,
CERT's definition of new is extremely different than that used on
bugtraq; CERT attempts to guarantee the existance of a fix for the
security hole before sending the mail, while bugtraq uses the mail to
guarantee a quick fix.

Comparison against CERT illustrates the true difference in philosophy
behind the bugtraq mailing list.  CERT perhaps epitomizes the
traditional response to security holes.  After being warned about a
new hole, they take time to verify that it is a hole.  Then they
contact the vendor or source of the software in question with the full
description of the hole.  When the vendor has a full fix for the hole
available, they send out a CERT Advisory on the subject.  This course
of action sounds great on paper, and seems extremely responsible.
Unfortunately, it doesn't work particularly well on the internet; CERT
has a reputation for being three to six months behind the times for
any given security hole.  Information spreads at such a rapid rate on
the Internet that within days of bug being discovered, there will be
source code distributed by crackers to exploit the bug.  The slowdowns
that CERT encounters are not always its own fault; although sometimes
it is lack of resources on CERT's part, more frequently the slowdown
occurs waiting for the software vendor to produce a fix.  CERT cannot
exert any sort of official pressure on a vendor to produce a fix, and
because CERT is keeping the bug report a secret, the vendor is not
necessarily receiving pressure from any other sources to get the bug
fixed faster.

Because CERT is in no way related to the government and has received
no official sanction for its work, it is constantly in fear of having
lawsuits brought against it.  Although no lawsuits have succeeded thus
far, apparently many have been threatened.  The reasons for these
lawsuits are varied, but usually center around the disclosure of
corporate secrets (that the company has been broken into in many
cases).  To avoid these lawsuits, CERT keeps a complete privacy
policy, whereby it will release no information at all about anyone who
comes to it, unless explicit permission is granted.  This hampers
investigation of cracking by other people because they cannot track
the activities of crackers and thus find their original service
provider.  This, combined with the typical slowness of CERT, leads to
annoyance and frustration with CERT by many system administrators and
security experts.  These professionals look for other methods of
increasing security on the Internet, which frequently means using
bugtraq.

The following quote from a posting by Alan Cox, a major contributor to
Linux, helps demonstrate this lack of faith.  
\singlespace
\begin{verbatim}
Date:         Mon, 26 May 1997 23:23:15 +0100
From:         Alan Cox <alan@CYMRU.NET>
Subject:      Announcement: Important

I've had various concerns when doing the Linux work with CERT, notably the
lack of work CERT does in releasing important bug reports when vendors
fail to release adequate fixes, and their lack of bug tracking for non
unix systems.

...

I no longer have any faith in CERT nor believe it is the right way to
handle the lamentably bad state of computer security today. It muddles along
like some kind of comic book 3rd world security agency trying to hide the
truth - the only reason we haven't had major computer security catastrophes
on the internet is because nobody has lit the fuse, not because we have
security.

...

Bugtraq has over 10,000 subscribers, things reported there generally get
fixed and I see little evidence of increased problems through its full
disclosure policy. In future I will instead be dealing with bugs I find
and learn about directly through bugtraq.

Alan Cox
EX Linux vendor contact
\end{verbatim}
\doublespace

A few examples and personal comments are removed from Alan's email, but
the tone is preserved.  This mailing sparked a long debate on the
bugtraq mailing list, one which generated many interesting comments.
The tone on the bugtraq list was very sympathetic to Alan, although
few people went as far as to decide to stop mailing bugs to CERT at
all (although many mentioned they would not wait for CERT to issue
its advisory).  No response from CERT was ever received.

A final issue many security professionals have with CERT is its
refusal to acknowledge the originator of a bug report.  Once a major
hole has been announced on bugtraq, CERT will frequently issue an
Advisory on the subject a couple days later, but having stripped most
details and all recognition of the initial discoverer of the hole.
CERT has ignored many emails questioning this policy, so guesses
abound as to its source, including protection of the exploit writer
from libel suits, preventing writer's reputation from influencing the
handling of a bug, and avoiding contentions on the true originator of
an exploit.  However, many exploit writers count on the reputation
they earn from their exploits to ensure contract positions in their
full time job as security consultants.  They are fully willing to risk
whatever lawsuits may be brought against them, because they posted the
bug in the first place.

\subsection{Other Mailing Lists}
\label{other-lists}

Bugtraq and CERT are by no means the only lists on which security
holes are discussed.  A wide variety of other lists exist, ranging
from application-specific lists to ultra-secret, low distribution
mailings.  Bugtraq is the perhaps best known of the security mailing
lists because of its age and size.  CIAC Notes (Computer Incident
Advisory Capability~\cite{CIAC}) is a mailing similar to CERT
Advisories, distributed by the Department of Energy, designed for
their employees and contractors, but distributed widely across the
Internet.  Best-of-Security~\cite{BOS} (BoS) is another moderated list
which receives reposts of the best mail sent to the above lists, plus
many others.  Volume on BoS tends to be much lower than that of
bugtraq, so many security experts prefer to read it, counting on all
the important messages to be forwarded.

Additionally, there is a fairly large set of invitation-only mailing
lists used by security professionals to discuss security holes and
exploits.  No one is sure how many of these there are, but they are
frequently the first lists to be informed of bugs, even before the
exploit gets posted to bugtraq.  In these cases, the lead time is
usually a day or too, to allow ultra-critical machines to be patched
before the bug is widely known.  Unfortunately, information about the
contents of these lists is not easily available, and so their impact
on security concerns is hard to judge.


\subsection{Cracker Information}
\label{cracker-sources}

One of the first questions about bugtraq most people ask is how much
it is used by crackers to obtain new exploits.  This is of course an
impossible question to answer because doing so would require polling
large numbers of crackers, a daunting task given the typical cracker
anti-authoritarian stance.  However, much can be said about bugtraq
usage by examining the sources of information crackers are known to
definitely use.  

\subsubsection{2600}
First, and perhaps most famous is 2600.  Published as a paper
magazine, as a usenet group (alt.2600), and on the web
(http://www.2600.com), 2600 is a group devoted to all forms of
hacking, ranging to phone phreaking to computer cracking.  Their
publications frequently contain information about new security hole
exploits, although the quality of information is often quite low for
computer related issues.  The print version of 2600 is primarily a
source of technical information, and because of it's space
constraints, rarely publishes very long exploit scripts, and those
that are published tend to be incomplete and buggy.

\subsubsection{IRC}
Second is \#hack, an IRC channel used by hackers to talk about hacks.
Although there are many different channels used by crackers, \#hack is
the most famous of them.  It is usually invitation only, meaning that
you need to have someone on the channel add you on, but this rarely
presents a problem, as most members of the channel are willing to add
anyone who asks.  Content on the channel varies widely in quality, but
it frequently contains pointers to the location of many exploit
scripts and people willing to explain how they work.  A full
examination of \#hack is beyond the scope of this paper, but the
realtime nature of IRC promotes extremely fast propagation of
information, and once an exploit has been announced anywhere, it is
usually mentioned on \#hack soon thereafter.

\subsubsection{Phrack}
Third is Phrack, along with all the other general-distribution cracker
electronic magazines.  Zines, as they are usually called, are
semi-regular publications sent over email, covering the latest
information on the given subject.  Phrack comes out roughly every
month, although much longer gaps are common.  It is devoted to
computer cracking and related material, and usually contains full
source code to exploits, as well as decent descriptions of how they
work.  Many of the exploits written in Phrack are of the
denial-of-service variety, where the exploiter uses the program to
prevent another user from obtaining some service, usually internet
service.  These denial-of-service scripts are popular because of the
vengeance theme on Phrack, and are often used by teenagers who feel
slighted by everyone else in the world.  There are about twenty or so
of these zines, some published yearly or even less frequently, but
they are all very similar in nature and can be safely grouped
together.

\subsubsection{Cracking Groups}
Fourth, and most importantly, are the core cracking groups themselves.
Legion of Doom and Masters of Destruction are two of the most famous,
and with good cause.  These groups are composed of the people who
actually write the exploit programs for crackers, and thus are the
source of many of the problems with crackers.  However, these groups
tend to tightly limit their membership and keep many of their exploits
private for a long time to extend their useful lifetime.  This is a trend
common among many crackers; they tend to be highly selfish, and want
to get all the use out of their new crack before sharing it, and
usually share it at all for ego satisfaction.  When crackers from
these core groups do share their exploits, it's usually via zines like
Phrack or a special zine their group puts out ocassionally.  These
groups are responsible for rootkit and most of the other extremely
common cracking tools, those found on almost every penetrated
machine.  

\subsubsection{Exploit Archives}
The final set of cracker distribution points are the archives, such as
http://www.rootshell.com, which contain many of the exploits posted
over the last few years.  These sites are particularly dangerous
because they frequently distribute the exploit source along with a
makefile so that anyone can copy the file, type {\bf make}, and
suddenly have a root shell on systems that have the particular bug
still open.  This is particularly important, because for many of the
young crackers on the Internet, compiling a program without a makefile is a
major challenge.  

\section{Problems with List Usage}
\label{problems}

As mentioned above, the biggest worry about the usage of the bugtraq
list is that crackers will use it as a source of exploits.  This is a
hard claim to evaluate, but based on the comparisons above, some
educated guesses can be made.  Between these five different sources of
information (~\ref{cracker-sources}), crackers already have a very
wide set of exploits available to use in attempting to gain root
access to a computer.  Most cracker tools originate with the cracking
groups, then are distributed widely by the other channels.  It is
difficult to prove that it is indeed these tools that are used by
crackers, but experience in examining the remains of a cracked
computer points towards this being the case.

If bugtraq were the only source of exploits available to hackers,
there would be a stronger rationale for it's disbanding.  However,
there are many other places that crackers can go to obtain exploits,
and from much more cracker friendly sources.  It is so easy to
publish information on the Internet that any cracker who finds an
exploit can give it to all his friends, plus anyone else who happens
to looking around.  

\section{Advantages of List Usage}
\label{advantages}

Simply showing that bugtraq doesn't do much harm isn't enough to
justify its existance.  The following are several arguments for why
the bugtraq should continue to exist and be used in its current format.

\subsection{Force Vendors to Take Action}
\label{vendors}

Perhaps the most important reason to post a security exploit to
bugtraq is to force a prompt response by the creator of the buggy
software.  Vendors selling programs are typically slow to respond to
problems reported by only one user due to the negligible financial
rewards for the effort required to fix the bug, but by involving all of
bugtraq (and word of mouth from there), a lot of separate complaints
are registered.  Additionally, vendors have traditionally been less
conscious about security issues because fewer machines were connected
to the Internet, and thus made vulnerable to many more remote
attacks.  The following piece of mail, again from bugtraq, clearly
shows this hesitance on the part of vendors in action:
\singlespace
\begin{verbatim}
Date:	      Sun, 22 Dec 1996 12:17:04 -0500
From:	      Chris Lavin <clavin@iag.net>
Subject:      Re: CERT, CIAC, etc. and unethical practices
Ok,
        Well we tried this recently with Sun! Sun in no uncertain terms
told us OH WELL!...That comes right from the Manager of teh Kernel group
Myron Kashima!...We have found a problem with Solaris X86 2.5.1. We could
put together a lil 20 line C program that would cause the kernel to hard
lock when a user opens a tcp socket to a machine that throwsa up a banner
reply (This inclusdes Suns own Mail machine). Well anyway we went around
with Sun for three months b4 we released the exploit to the newsgroups and
on bugtraq. We have tried the diplomatic route IT DON'T WORK!..So maybe if
a few people start to crash X86 systems Sun will do the right thing and
fix the bug. Oh did I fail to mention that Sun would be willing to fix the
bug if we BOUGHT a contract and paid them for their time?...Thanx

       Chris Lavin <clavin@iag.net> The Internet Access Group, Inc.
\end{verbatim}
\doublespace

\subsection{Teach Security Awareness}

As mentioned above, the mindset involved in secure programming is very
different than the mindset of traditional programming.  By posting
exploits to bugtraq, more programmers see what structures in the
original code were faulty, and what steps need to be taken in the
future to create more bulletproof code.  Thus, the programming
community is strengthened, and a new generation of security experts is
ensured.

\subsection{Maintain interest in Security}

Finally, bugtraq can truly be interesting.  The exploits posted to it
are intriguing and challenging to understand, and many programmers
read it for enjoyment.  Finding a security hole and providing a fix
for it is considered a true mark of an experienced programmer, and the
recognition gained via a good post to bugtraq can be very important to
security experts.  Without bugtraq, a lot of the interest in security
could dry up, leaving computer security in a mode where security holes
were only reacted to once exploited by crackers, rather than sought
out before they are exploited.  Security through obscurity is not a
good security policy, despite many vendors' thoughts, and bugtraq
helps force constant advancement in the area.

\section{Usage Guidelines}

Given the number of advantages of bugtraq, and its limited
disadvantages, the forum seems to be a powerful tool for security
administrators.  However, there are still some cases when bugtraq may
not be the best solution.  For example, if the supplier for the broken
code is known to fix bugs extremely promptly, then simply notifying
him and creating a fixed version of the program will be faster and
less painful than going through bugtraq (which the original author may
not read).  Or consider the handling of a bug in the routers that
control the Internet, allowing a cracker to turn off the router; a
tool like this could cripple the Internet, and thus might want to be
kept hidden until a fix is available.  This is of course a judgement
call --- some might set this boundary far lower, and returns to the
original question of why bugtraq is useful.  There are limitless
special cases in handling security holes because this is a very hazy
area, and so individual discretion must be exercised.

\section{Conclusion}

Although bugtraq may appear to recklessly distribute dangerous tools
to an unfiltered group, there remain strong reasons for the continued
use of the list.  First, it many instances it is the only method
available to force a vendor to fix a dangerous security hole in one of
their products.  Second, the public discussion of security related
code increases the awareness of safety precautions needed within
critical code.  Third, the bugtraq list helps foster and continue the
Internet security community, itself another valuable resource for system
administrators.  Finally, it is unclear that the bugtraq list is
heavily used by the cracker community, because it has its own sources
of cracking tools that appear to be unrelated to bugtraq.  Bugtraq may
not always be the best solution, and user discretion is advised, but
it is a powerful tool and one that should be preserved.

\newpage
\begin{singlespace}
{\raggedright
\bibliography{bugtraq}}
\bibliographystyle{plain}
\end{singlespace}

\end{document}
