ch15.htm

来自「Maximum Security (First Edition) 网络安全 英文」· HTM 代码 · 共 1,211 行 · 第 1/4 页

	COLOR="#000000">.</FONT> 
<HR>


</BLOCKQUOTE>

<PRE></PRE>
<P>Older versions of sendmail contain a weakness in the buffer (you will learn a
little bit about the buffer/stack scenario in the following paragraphs). As such,
one used to be able to crack the system by invoking the <TT>debug</TT> option in
sendmail and overflowing the buffer. This was done with the <TT>-d</TT> option. A
similar problem surfaced regarding sendmail's communication with the <TT>syslog</TT>
daemon (another buffer overflow problem).</P>
<P>These types of holes represent a serious threat for one reason: If a local user
successfully manages to exploit such a hole, the system administrator may never discover
it. Also, leveraged access is far more dangerous in the hands of a local user than
an outsider. This is because a local user can employ basic system utilities to learn
more about the local network. Such utilities reveal far more than any scanner can
from the void. Therefore, a local user with even fleeting increased access can exploit
that access to a much greater degree. (For that matter, the local user is <I>behind</I>
your firewall, meaning he is free to conduct his affairs without further complications.)


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>Holes in programs like sendmail
	are especially significant because these programs are available to all users on the
	network. All users must have at least basic privileges to use the sendmail program.
	If they did not, they would have no way to send mail. Therefore, any bug or hole
	within sendmail is very dangerous. 
<HR>


</BLOCKQUOTE>

<P>The only real comfort with respect to these types of holes is that there is a
much greater chance of identifying the offender, particularly if he is inexperienced.
If the system administrator is running strong logging utilities, the offender will
need a fair amount of expertise to escape detection.
<H4><FONT COLOR="#000077"><B>Other Class B Holes</B></FONT></H4>
<P>Most class B holes arise from some defect within an application. There are some
fairly common programming errors that lead to such holes. One such error concerns
the character buffer in programs written in C (hence, the dreaded buffer overflow).<I>
Buffer overflow</I> is defined on the Jargon File as

<DL>
	<DD>What happens when you try to stuff more data into a buffer (holding area) than
	it can handle. This may be due to a mismatch in the processing rates of the producing
	and consuming processes (see overrun and firehose syndrome), or because the buffer
	is simply too small to hold all the data that must accumulate before a piece of it
	can be processed.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The Jargon File is a
	wide collection of definitions, which cover strange and colorful terms used in computer
	lingo or slang (technospeak). All new Internet users should peruse the Jargon File
	because it reveals the meanings of many acronyms and other slang terms referred to
	in Usenet newsgroups and general discussion areas on the Internet. A good HTML version
	of the Jargon File is located at <A HREF="http://nmsmn.com/~cservin/jargon/alpha.html"><TT>http://nmsmn.com/~cservin/jargon/alpha.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>Rather than exhaustively treat the subject of buffer overflows, I will briefly
describe problem here. The purpose of this explanation is to familiarize you with
a rather ingenious technique of gaining unauthorized access; I hope to do so without
an endless examination of the C language (C is covered more extensively in Chapter
30, &quot;Language, Extensions, and Security&quot;).</P>
<P>Programs written in C often use a <I>buffer</I>. Flatly stated, a buffer is an
abstraction, an area of memory in which some type of text or data will be stored.
Programmers make use of such a buffer to provide pre-assigned space for a particular
block or blocks of data. For example, if one expects the user to input his first
name, the programmer must decide how many characters that first name buffer will
require (how many letters should be allowed in that field, or the number of keystrokes
a user can input in a given field). This is called the size of the character buffer.
Thus, if the programmer writes:</P>
<PRE><FONT COLOR="#0066FF">char first_name[20];
</FONT></PRE>
<P>he is allowing the user 20 characters for a first name. But suppose the user's
first name has 35 characters. What happens to the last 15 characters? They overflow
the character buffer. When this overflow occurs, the last 15 characters are put somewhere
in memory, at another address (an address the programmer did not intend for those
characters to go to). Crackers, by manipulating where those extra characters end
up, can cause arbitrary commands to be executed by the operating system. Most often,
this technique is used by local users to gain access to a root shell. Unfortunately,
many common utilities have been found to be susceptible to buffer overflow attacks.</P>
<P>Programmers can eliminate this problem through careful programming techniques.
I am not suggesting here that programmers should provide error checking for each
and every character buffer written; this is probably unrealistic and may be waste
of time. For although these defects can certainly place your network at risk, the
cracker requires a high level of skill to implement a buffer overflow attack. Although
the technique is often discussed in cracking circles, few actually have the programming
knowledge to do it.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>Failure to include checks for buffer
	overflows have caused some of the very problems I have already discussed, such as
	sendmail holes. 
<HR>


</BLOCKQUOTE>

<P>The buffer overflow issue is nothing new; it has been with us at least since the
days of the Worm. Eugene Spafford, as I have already noted, was one of the first
individuals to conduct a purposeful analysis of the Worm. He did so in the now-famous
paper, &quot;The Internet Worm: An Analysis.&quot; Spafford's paper is undoubtedly
the best source of information about the Worm.</P>
<P>In page 4 of that document, Spafford observes that the Morris Worm exploited a
vulnerability in the fingerd daemon (the daemon that listens for and satisfies finger
requests directed to port 79). The fingerd program utilized a common C language function
known as <TT>gets()</TT>, which performs the simple task of reading the next line
of input. <TT>gets()</TT> lacked any function to check for <I>bounds</I>, or incoming
input that could potentially exceed the buffer. Thus, Morris was able to overflow
that buffer and reportedly push other code onto the stack; this code provided the
Worm with needed system access. Spafford observes that this vulnerability was well
known in programming communities, even then. He further explains that functions that
fail to check for potential overflows should not be used. Yet even today, programs
are written with the same, basic flaws that allowed the Worm to travel so far, so
fast.
<H3><FONT COLOR="#000077"><B>Holes That Allow Remote Users Unauthorized Access (Class
A)</B></FONT></H3>
<P>Class A holes are the most threatening of all and not surprisingly, most of them
stem from either poor system administration or misconfiguration. Vendors rarely overlook
those holes that allow remote users unauthorized access. At this late stage of the
game, even vendors that were previously not security minded have a general grasp
of the terrain.</P>
<P>The typical example of a misconfiguration (or configuration failure) is any sample
script that remains on the drive, even though the distribution docs advise that it
be removed. One such hole has been rehashed innumerable times on the Net. It involves
those files included within Web server distributions.</P>
<P>Most Web server software contains fairly sparse documentation. A few files may
exist, true, and some may tout themselves as tutorials. Nonetheless, as a general
rule, distributions come with the following elements:

<UL>
	<LI>Installation instructions<BR>
	<BR>
	
	<LI>The binaries<BR>
	<BR>
	
	<LI>In some rare cases, the source<BR>
	<BR>
	
	<LI>Sample configuration files with comments interspersed within them, usually commented
	out within the code<BR>
	<BR>
	
	<LI>Sample CGI scripts
</UL>

<P>To the credit of those distributing such software, most configuration files offer
a warning regarding sample scripts. Nonetheless, for reasons of which I am uncertain,
not everyone heeds those warnings (at least one government site recently cracked
had this problem). In any case, these scripts can sometimes provide an intruder from
the void with access ranging from limited to root.</P>
<P>Probably the most talked-about hole of this kind is the vulnerability in a file
called <TT>test-cgi</TT>, distributed with early versions of the Apache Web Server
distribution. This file contained a flaw that allowed intruders from the void to
read files within the CGI directory. If your <TT>test-cgi</TT> file contained the
following line, you were probably vulnerable:</P>
<PRE><FONT COLOR="#0066FF">echo QUERY_STRING = $QUERY_STRING
</FONT></PRE>
<P>As noted in the article titled &quot;Test-CGI Vulnerability in Certain Setups&quot;:

<DL>
	<DD>All of these lines should have the variables enclosed in loose quotes (&quot;).
	Without these quotes certain special characters (specifically `*') get expanded where
	they shouldn't. Thus submitting a query of `*' will return the contents of the current
	directory (probably where all of the cgi files are).
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Find &quot;Test-CGI Vulnerability
	in Certain Setups&quot; online at <A HREF="http://www.sec.de/sec/bug.testcgi"><TT>http://www.sec.de/sec/bug.testcgi</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>Interestingly, no sooner than this advisory (and others like it) circulated, it
was found that:

<DL>
	<DD>Test-CGI in the Apache 1.1.1 distribution already has the required:
</DL>



<BLOCKQUOTE>
	<PRE><FONT COLOR="#0066FF">echo QUERY_STRING = &quot;$QUERY_STRING&quot;</FONT></PRE>

</BLOCKQUOTE>


<DL>
	<DD>However, it does not have the necessary quotes around the
</DL>



<BLOCKQUOTE>
	<PRE><FONT COLOR="#0066FF">&quot;$CONTENT_TYPE&quot;</FONT></PRE>

</BLOCKQUOTE>


<DL>
	<DD>string. Therefore it's still vulnerable in its default configuration.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The previous paragraph
	is excerpted from an article titled &quot;Vulnerability in Test-CGI&quot; by Joe
	Zbiciak. It can be found online at <A HREF="http://geek-girl.com/bugtraq/"><TT>http://geek-girl.com/bugtraq/</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>Problems like this are common. For example, one HTTP server on the Novell platform
includes a sample script called <TT>convert.bas</TT>. The script, written in BASIC,
allows remote users to read any file on the system.</P>
<P>This problem sometimes involves more than just a sample script; sometimes it involves
the way scripts are interpreted. For example, version 1.0 of Microsoft's Internet
Information Server (IIS) contains a hole that allows any remote user to execute arbitrary
commands. The problem is that the IIS HTTP associates all files with a <TT>*.bat</TT>
or <TT>*.cmd</TT> extension to the program <TT>cmd.exe</TT>. As explained by Julian
Assange (author of Strobe), the problem is not restricted to IIS:

<DL>
	<DD>The First bug allows a user to access any file on the same partition where your
	wwwroot directory exists (assuming that IIS_user has permission to read this file).
	It also allows execution of any executable file on the same partition where your
	scripts directory exists (assuming that IIS_user has permission to execute this file).
	If cmd.exe file can be executed then it also allows you to execute any command and
	read any file on any partition (assuming that IIS_user has permission to read or
	execute this file)...Unfortunately Netscape Communication and Netscape Commerce servers
	have similar bugs. Similar things can be done with Netscape Server if it uses BAT
	or CMD files as CGI scripts.
</DL>

<P>Naturally, these holes pose a significant danger to the system from outside sources.
In many cases, if the system administrator is running only minimal logs, these attacks
may go unrecorded. This makes it more difficult to apprehend the perpetrators.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>To be fair, most UNIX implementations
	of HTTPD do provide for recording of the requesting IP address. However, even given
	this index to go by, identifying the actual perpetrator can be difficult. For example,
	if the attacker is coming from AOL, the call will come from one or more of AOL's
	proxy machines in Reston, Virginia. There could be hundreds of potential suspects.
	Using the <TT>ACCESS.LOG</TT> file to track a cracker is a poor substitute for more
	comprehensive logging and is only of real value when the attacker is coming from
	a small local ISP. 
<HR>


</BLOCKQUOTE>

<P>You can readily see, then, why programs like scanners have become such an important
part of the security scheme. Scanners serve the vital purpose of checking for these
holes. The problem is, of course, that for a scanner to include the capability to
scan for a particular vulnerability, that vulnerability must already be well known.
Thus, although security programmers include such holes as scan options in their programs,
they are often several months behind the cracking community. (Also, certain holes--such
as the syn_flooding hole that allows denial-of-service attacks--are not easily remedied.
Such holes are imperfections that system administrators must learn to live with for
the moment.)</P>
<P>What makes the situation more difficult is that holes on platforms other than
UNIX take more time to surface. Many NT system administrators do not run heavy logs.
To report a hole, they must first have some evidence that the hole exists. Moreover,
newer system administrators (of which a higher percentage exists amongst the IBM-compatible
set) are not well prepared for documenting and reporting security incidents. This
means that time passes before such holes are presented, tested, re-created in a test
environment, and ultimately, implemented into scanners.