ch15.htm

Maximum Security (First Edition) 网络安全 英文版

<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>Microsoft users cannot count on
	Microsoft to instantly enlighten users as to potential problems. In my opinion, Microsoft's
	record of publicizing holes has been very poor. It seems to do so only after so many
	people know about the hole that there is no other choice but to acknowledge it. While
	a hole is still obscure, Microsoft personnel adamantly deny the existence of the
	flaw. That situation is only now changing because the hacking (not cracking) community
	has called their bluff and has initiated the process of exposing all holes inherent
	within the Microsoft platform. 
<HR>


</BLOCKQUOTE>

<P>There is also the question of quality. Five years ago, software for the Internet
was coded primarily by the academic communities. Such software had bugs, true, but
the quality control worked quite differently from today's commercial schemes. In
those days (they seem so distant now!), a product was coded by and released from
some CS lab. Several hundred (or even several thousand) people would download the
product and play with it. Bug reports would flow in, problems would be addressed,
and ultimately, a slow but progressive process of refinement would ensue.</P>
<P>In the current commercially charged climate of the Internet, applications of every
type are popping up each day. Many of them are not subjected to a serious analysis
for security flaws within the code (no matter how fervently their proponents urge
otherwise). In fact, it is common to see the same programming errors that spawned
the Morris Worm.</P>
<P>To demonstrate this point, I will refer to the buffer overflow problem. As reported
in a 1995 advisory on a vulnerability in NCSA HTTPD (one of the world's most popular
Web server packages):

<DL>
	<DD>A vulnerability was recently (2/17/95) discovered in the NCSA httpd Release 1.3.
	A program which will break into an HP system running the precompiled httpd has been
	published, along with step by step instructions. The program overflows a buffer into
	program space which then gets executed.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The previous paragraph
	is excerpted by a paper by Elizabeth Frank, and can be found online at <A HREF="http://ernie.sfsu.edu/patch_desc.html"><TT>http://ernie.sfsu.edu/patch_desc.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>According to the CERT advisory (&quot;NCSA HTTP Daemon for UNIX Vulnerability&quot;)
that followed:

<DL>
	<DD>Remote users may gain unauthorized access to the account (uid) under which the
	httpd process is running.
</DL>

<P>As explained in Chapter 9, &quot;Scanners,&quot; many individuals unwittingly
run HTTPD as root. Thus, this vulnerability would provide remote users with root
access on improperly configured Web servers.
<H2><FONT COLOR="#000077"><B>Other Holes</B></FONT></H2>
<P>In the preceding paragraphs, I named only a few holes. This might give you the
erroneous impression that only a handful of programs have ever had such holes. This
is untrue. Holes have been found in nearly every type of remote access software at
one stage or another. The list is very long indeed. Here is a list of some programs
that have been found (over the years) to have serious class A holes:

<UL>
	<LI>FTP
	<LI>Gopher
	<LI>Telnet
	<LI>sendmail
	<LI>NFS
	<LI>ARP
	<LI>Portmap
	<LI>finger
</UL>

<P>In addition to these programs having class A holes, all of them have had class
B holes as well. Moreover, in the class B category, dozens of other programs that
I have not mentioned have had holes. Finally, a good number of programs have class
C holes as well. I will be addressing many of these in upcoming chapters.
<H2><FONT COLOR="#000077"><B>The Impact of Holes on Internet Security</B></FONT></H2>
<P>Now that you have read a bit about some common holes, the next step is to know
what impact they can have on Internet security. First, know this: <I>Any flaw that
a cracker can exploit will probably lead to other flaws</I>. That is, each flaw (large
or small) is a link in the network chain. By weakening one link, crackers hope to
loosen all the other links. A true cracker may use several techniques in concert
before achieving even a modest goal. If that modest goal can be achieved, other goals
can also be achieved.</P>
<P>For example, perhaps a cracker is working on a network on which he does not have
an account. In that instance, he must first acquire some form of access to the system
(access above and beyond whatever diagnostic information he may have culled from
SATAN, ISS, or other scanners). His first target, then, might be a user on that network.
If he can compromise a user's account, he can at least gain shell access. From that
point on, other measures may be taken.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>I recently reviewed logs on a case
	where the cracker had gained control of a local user's account. Unfortunately for
	the cracker, he did not pick his target well. The unwary user was a complete newbie
	and had never, ever used her shell account. LAST logs (and other auditing materials)
	revealed this immediately. So what we had was a dial-up customer who had never used
	her shell account (or even built a Web page) suddenly compiling programs using a
	C compiler from a shell account. Hmm. Next time, that cracker will be more choosy
	about whose account he commandeers. 
<HR>


</BLOCKQUOTE>

<H3><FONT COLOR="#000077"><B>Is This Hole Problem As Bad As They Say?</B></FONT></H3>
<P>Yes and no. Holes are reported to a variety of mailing lists each day. Nonetheless,
those holes vary in severity. Many are in the class C category and not particularly
important. As an interesting experiment, I decided to categorize (by operating-system
type) all holes reported over a two-month period.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>In my experiment, I excluded all
	non-UNIX operating systems (I treat non-UNIX operating systems later in this chapter).
	I did this to be fair, for by sampling a bug mailing list that concentrates primarily
	on UNIX machines, I would give an erroneously bad image of UNIX and an erroneously
	good image of non-UNIX systems. This is so because UNIX mailing lists only occasionally
	receive security advisories on non-UNIX systems. (Although there is now a cross-over
	because other systems are more commonly being used as server-based platforms for
	the WWW, that cross-over amounts to a trickle). 
<HR>


</BLOCKQUOTE>

<P>Instead of indiscriminately picking instances of a particular operating system's
name and adding this to the tables (for example, grabbing every posting that referred
to the syslog hole), I carefully sifted through each posting. I chose only those
postings that reported the first instance of a hole. All trailing messages that discussed
that hole were excluded. In this way, only new holes were added to my data. Furthermore,
I pulled only the first 50 on each operating system. With one minor exception that
I explain later, I had no reason to assume that the percentage would be greatly influenced
by pulling 100 or 1,000.</P>
<P>I must advise you of one final point. Figure 15.2 shows an astonishing number
of holes in HP-UX (Hewlett Packard's OS). This prevalence of HP-UX holes is largely
due to a group called &quot;Scriptors of Doom.&quot; These individuals have concentrated
their efforts on finding holes indigenous to HP-UX. They have promised &quot;one
hole a week.&quot; Because of their activity, HP-UX appears to have security problems
that are more serious than other operating systems of a similar ilk. This is not
really the case. That settled, please examine Figure 15.2.</P>
<P>Note that Sun (Solaris), AIX, and FreeBSD were running neck and neck, and that
IRIX had just slightly fewer holes than Linux. But which of these holes were serious
security risks? Which of these--per platform--were class B or class A vulnerabilities?
To determine this, I reexamined the data from Figure 15.2 and excluded all vulnerabilities
that could not result in local or remote users gaining root access. Table 15.1 lists
the results.</P>
<P><A HREF="02.htm"><B>FIGURE 15.2.</B></A> <BR>
<I>Survey of reported operating system holes in October-December 1996.</I>
<H4><FONT COLOR="#000077"><B>Table 15.1. Operating system holes that allowed root
access.</B></FONT></H4>
<P>
<TABLE BORDER="1">
	<TR ALIGN="LEFT" rowspan="1">
		<TD ALIGN="LEFT" VALIGN="TOP"><I>Operating system</I></TD>
		<TD ALIGN="LEFT" VALIGN="TOP"><I>Holes</I></TD>
	</TR>
	<TR ALIGN="LEFT" rowspan="1">
		<TD ALIGN="LEFT" VALIGN="TOP">HP-UX</TD>
		<TD ALIGN="LEFT" VALIGN="TOP">6</TD>
	</TR>
	<TR ALIGN="LEFT" rowspan="1">
		<TD ALIGN="LEFT" VALIGN="TOP">Solaris</TD>
		<TD ALIGN="LEFT" VALIGN="TOP">2</TD>
	</TR>
	<TR ALIGN="LEFT" rowspan="1">
		<TD ALIGN="LEFT" VALIGN="TOP">AIX</TD>
		<TD ALIGN="LEFT" VALIGN="TOP">1</TD>
	</TR>
	<TR ALIGN="LEFT" rowspan="1">
		<TD ALIGN="LEFT" VALIGN="TOP">Linux</TD>
		<TD ALIGN="LEFT" VALIGN="TOP">4</TD>
	</TR>
	<TR ALIGN="LEFT" rowspan="1">
		<TD ALIGN="LEFT" VALIGN="TOP">IRIX</TD>
		<TD ALIGN="LEFT" VALIGN="TOP">4</TD>
	</TR>
	<TR ALIGN="LEFT" rowspan="1">
		<TD ALIGN="LEFT" VALIGN="TOP">FreeBSD</TD>
		<TD ALIGN="LEFT" VALIGN="TOP">3</TD>
	</TR>
</TABLE>
</P>
<P>Still, this information could be misleading, so I analyzed the data further. All
of the listed operating systems were vulnerable to at least one bug present in their
counterparts. That is, at least one bug was common to all operating systems sampled.
After excluding these holes, the average was 2.5 holes per platform. AIX fell completely
out of the running at that stage, having a total value of 0. Does this mean that
AIX is the safest platform? No. It simply means that this two-month period spawned
few advisories relevant to AIX.</P>
<P>This brings me to an important point. You may often see, particularly on Usenet,
individuals arguing over whether Solaris is tighter than AIX or whether Linux is
tighter than FreeBSD and so forth. These arguments are exercises in futility. As
it happens, all operating systems have their holes. Long-term examination of reporting
lists reveals that advisories go in cycles. Were I to sample another period in time,
AIX might be the predominate victim. There is no mysterious reason for this; it breaks
down to the nature of the industry. When a hole is discovered in sendmail, for example,
it is not immediately clear as to which platforms are affected. Determining this
takes time. When the hole is confirmed, a detailed description is posted to a list,
and chances are that more than half of all machines running sendmail are affected.
But when holes are discovered in proprietary software, any number of things can happen.
This might result in a one-month run of advisories on a single platform.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>This sometimes happens because proprietary
	software may have multiple file dependencies that are inherent to the distribution,
	or there may be multiple modules created by the same programming team. Therefore,
	these executables, libraries, or other files may share the same basic flaws. Thus,
	there may be a buffer overflow problem in one of the executable programs in the package,
	and additionally, one of the library implementations is bad. (Or even, systems calls
	are poorly implemented, allowing commands to be pushed onto the stack.) If a proprietary
	package is large, problems could keep surfacing for a week or more (maybe even a
	month). In these cases, the vendor responsible looks very bad; its product is a topic
	of furious discussion on security lists for an extended period. 
<HR>


</BLOCKQUOTE>

<H4><FONT COLOR="#000077"><B>Holes on Other Platforms</B></FONT></H4>
<P>Analyzing holes on other platforms is more difficult. Although vendors maintain
documents on certain security holes within their software, organized reporting (except
in cases if virus attacks) has only recently become available. This is because non-UNIX,
non-VAX systems have become popular server platforms only in the last two years.</P>
<P>Reporting for these holes has also been done (up until recently) by individual
users or those managing small networks. Hard-line security professionals have traditionally
not been involved in assaying, for example, Microsoft Windows. (Oh, there are hundreds
of firms that specialize in security on such platforms, and many of them are listed
in this book. Nonetheless, in the context of the Internet, this has not been the
rule.)


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>That rule is about to change. Because
	security professionals know that Microsoft Windows NT is about to become a major
	player, reporting for NT holes will become a more visible activity. 
<HR>


</BLOCKQUOTE>

<H2><FONT COLOR="#000077"><B>Discussions About Holes on the Internet</B></FONT></H2>
<P>Finding information about specific holes is simple. Many sites, established and
underground, maintain archives on holes. Established sites tend to sport searchable
indexes and may also have classic security papers ranging back to the days of the
Worm. Underground sites may have all of this, as well as more current information.
The majority of holes, in fact, are circulated among cracking communities first.
For information about locating these resources, see Appendix A, &quot;How to Get
More Information.&quot; To whet your appetite, a few sites and sources for information
about security holes follow.
<H3><FONT COLOR="#000077"><B>World Wide Web Pages</B></FONT></H3>
<P>You'll find loads of information about holes on numerous Web pages. Following
are some that you should check out.
<H4><FONT COLOR="#000077"><B>CERT</B></FONT></H4>
<P>The Computer Emergency Response Team was established after the Internet Worm debacle
in 1988 (young Morris scared the wits out of many people on the Net, not the least
of which were those at DARPA). CERT not only issues advisories to the Internet community
whenever a new security vulnerability becomes known, it

<UL>
	<LI>is on call 24 hours a day to provide vital technical advice to those who have
	suffered a break-in<BR>
	<BR>
	
	<LI>uses its WWW site to provide valuable security information available, both new
	and old (including papers from the early 1980s)<BR>
	<BR>
	
	<LI>publishes an annual report that can give you great insight into security statistics
</UL>

<P>The real gold mine at CERT is the collection of advisories and bulletins. You
can find these and other important information at <A HREF="http://www.cert.org"><TT>http://www.cert.org</TT></A>
(see Figure 15.3).</P>
<P><A NAME="03"></A><A HREF="03.htm"><B>FIGURE 15.3.</B></A> <BR>
<I>The Computer Emergency Response Team (CERT) WWW site.</I>
<H4><FONT COLOR="#000077"><B>Department of Energy Computer Incident Advisory Capability</B></FONT></H4>
<P>CIAC was also established in 1989, following the Morris Worm. This organization
maintains a database of security related material intended primarily for the U.S.
Department of Energy. The CIAC site is one of the best sources for security information.
In addition to housing tools, this site also houses a searchable archive of security
advisories. Moreover, CIAC provides to the public a series of security papers. Also,
CIAC now utilizes the Adobe PDF file format, so the papers it provides are attractive,
easily navigated, and easily formatted for printing. PDF format is, in my opinion,