ch29.htm

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

</BLOCKQUOTE>

<P>If you are a Mac or PC user currently using NCSA Telnet (with the FTP server),
disallow all FTP access to anyone you do not trust. If you fail to heed this warning,
you may get cracked. Imagine a scenario where a single individual on a network was
using NCSA Telnet. Even if the rest of the network was reasonably secure, this would
blow its security to pieces. Moreover, the application does not perform logging (in
the normal sense) and therefore, no trail is left behind. Any network running this
application can be attacked, disabled, or destroyed, and no one will be able to identify
the intruder.</P>
<P>The most interesting Telnet hole ever discovered, though, was related to the environment
variable passing option. The DDN bulletin on it was posted on November 20, 1995:

<DL>
	<DD>A vulnerability exists in some versions of the Telnet daemon that support RFC
	1408 or 1572, both titled the &quot;Telnet Environment Option,&quot; running on systems
	that also support shared object libraries...Local and remote users with and without
	local accounts can obtain root access on the targeted system.
</DL>

<P>Many sites suffer from this vulnerability. To understand the problem, you must
understand the term <I>environment</I>. In UNIX vernacular, this generally refers
to the environment of the shell (that is, what shell you might use as a default,
what terminal emulation you are using, and so forth).


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>DOS/Windows users can most easily
	understand this by thinking about some of the statements in their <TT>AUTOEXEC.BAT</TT>
	and <TT>CONFIG.SYS</TT> files. For example, variables are established using the <TT>SET</TT>
	command, as in <TT>SET PATH=C:\;C:\WINDOWS;</TT> (the <TT>PATH</TT> environment variable
	is one of several that can be specified in the DOS environment). These statements
	define what your programming environment will be like when you boot into command
	mode. Some common environment variables that can be set this way are the shell you
	are using, the path, the time zone, and so forth. 
<HR>


</BLOCKQUOTE>

<H4><FONT COLOR="#000077"><B>Changing the Environment</B></FONT></H4>
<P>In UNIX, you can view or change the environment by using either the <TT>setenv</TT>
or <TT>printenv </TT>command. Here is an example of what one might see on such an
instruction:</P>
<PRE><FONT COLOR="#0066FF">&gt; setenv

ignoreeof=10
HOSTNAME=samshacker.samshack.net
LOGNAME=tr
MINICOM=-c on
MAIL=/spool/mail/samshack
TERM=ansi
HOSTTYPE=i386-linux
PATH=/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:.
HOME=/usr/local/etc/web-clients/samshacker/./
SHELL=/bin/bash
LS_OPTIONS=--8bit --color=tty -F -T 0
PS1=\h:\w\$
PS2=&gt;
TAPE=/dev/nftape
MANPATH=/usr/local/man:/usr/man/preformat:/usr/man:/usr/X11/man:/usr/openwin/man
LESS=-MM
OSTYPE=Linux
OPENWINHOME=/usr/openwin
SHLVL=2
BASH=/bin/bash
LS_COLORS=
_=/bin/csh
PWD=/usr/local/etc/web-clients/samshacker/./
USER=tr
HOST=samshack
</FONT></PRE>
<P>This listing is a very extensive output of the command on a machine on which a
virtual domain has been established. A more manageable (and more easily explained)
version can be taken from a bare shell machine. Here is the output:</P>
<PRE><FONT COLOR="#0066FF">samshacker% /usr/ucb/printenv
HOME=/home/hacker
HZ=100
LOGNAME=hacker
MAIL=/var/mail/hacker
PATH=/usr/bin:
SHELL=/sbin/sh
TERM=ansi
TZ=US/Pacific
PWD=/home/hacker
USER=hacker
</FONT></PRE>
<P>This output is from a SPARCstation 10 on which I set up a mock shell account (the
first output was from a Linux box). This is a very stripped-down environment. The
<TT>PATH</TT> statement (line 6) points only to <TT>/usr/bin</TT>. In practice, this
is impractical because there are many more binaries on a UNIX system than those located
in <TT>/usr/bin</TT>. For example, there are binaries located in <TT>/usr/sbin</TT>,
<TT>/usr/bin/X11</TT>, and so forth. You can see, for example, that even the command
given (<TT>setenv</TT>) was done by issuing the absolute path statement (<TT>/usr/ucb/setenv</TT>).
In practice, I would have (within a day or so) set a much longer path, pointing to
man pages, binaries, and perhaps even include directories.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>The <TT>PATH</TT> statement in UNIX
	works almost exactly as it does in DOS. Directories that you intend to be in the
	path must be articulated on the <TT>PATH</TT> statement line and separated by colons
	(instead of semicolons). By articulating these on the <TT>PATH</TT> line, you give
	the user access to commands within these directories (no matter which directory the
	user is currently located in). 
<HR>


</BLOCKQUOTE>

<H4><FONT COLOR="#000077"><B>Terminal Emulation</B></FONT></H4>
<P>Other variables set in the preceding statements include <TT>HOME</TT>, <TT>MAIL</TT>,
<TT>SHELL</TT>, and <TT>TERM</TT>. <TT>TERM</TT>, one of the most important variables,
expresses the type of <I>terminal emulation</I> that you will be using. Because not
all readers know what terminal emulation is, I want to quickly explain it.</P>
<P>Years ago, the majority of servers were mainframes. In those days, users did not
have powerful PCs attached to the mainframe; they had <I>terminals</I>, which were
(usually) boxes without hard drives. These were screens attached to keyboards. Behind
terminals were a series of connectors, which might offer different methods of connection.
One popular method was a bare-bones serial connection (we're talking primitive here:
a straight serial-to-serial interface). Other terminals might sport hardwire options
such as Ethernet connections.</P>
<P>In any event, these terminals had very little functionality (at least in comparison
to the average PC). Contained on the main board of such a terminal was a small portion
of memory and firmware (software hardwired into the board itself). This firmware
would grant the user several options. For example, one could set the speed and type
of connection, the need for local echo, and so forth. Sometimes, there were options
to set the type of printer that might be used or even what port the data was to be
sent from.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>TIP:</B></FONT><B> </B>Such terminals are still sold on
	certain Usenet newsgroups. If you are a student with limited funds and you have been
	granted some form of Ethernet or even serial connection to your college's server,
	and if that server account is a shell account, get a terminal. For a mere $25-40,
	you can get high-speed access to the Internet. True, you cannot generally save materials
	to a disk, but you can print what is currently on the screen. You will not believe
	how quickly the screen will update. It is the absolutely ideal situation for Internet
	Relay Chat (IRC). These boxes are small, cheap, and fast. 
<HR>


</BLOCKQUOTE>

<P>The two best-known terminals were the Tektronix 4010 and the VT100 (also the IBM
3270, which is a bit different). Each had a set number of characters per line and
lines per screen that could be displayed. In fact, most terminals usually had two
settings. As terminals became more fancy, one could even set columns and, eventually,
graphics (the Tektronix was graphics oriented).</P>
<P>Because these terminals became the standard method of connecting to mainframes,
they also bled into the UNIX world. As such, all UNIX operating systems have keyboard
and screen mappings for terminals. <I>Mappings</I> are descriptions of the screen
and the keyboard settings (for example, how many lines and columns per screen or,
more importantly, what Ctrl key sequences represent special characters). These are
required because certain terminals use more keys than are offered on the standard
PC or Mac keyboard. In addition to the regular typewriter keyboard and F function
keys, there may be P keys that perform special actions, including the activation
of menus and the navigation of the screen cursor in databases. To make up for this
on PC, Mac, or even some UNIX keyboards, Esc or Ctrl sequences are defined. These
are combinations of keystrokes that equal a P key. These key assignments are called
<I>key</I> <I>bindings</I>, which are statements made within the program code that
define what happens if this or that key combination is executed. Key bindings are
a big part of programming, especially in C where you offer a semi-graphical interface
(for example, where you use Borland's famous TurboVision libraries to create drop-down
menus in a DOS application).</P>
<P>One can generally define key bindings in a program (at least, in a well written
one). This gives the user application-level control over which keys do what. For
example, perhaps the user can set the binding of the Ctrl key plus the letter <I>F</I>
to perform a variety of functions. Some specialized applications actually ask the
user to do so before launching the program for the first time. There is one such
program--a freeware editor for UNIX, written in Germany--that allows you to completely
remap the keyboard.</P>
<P>In UNIX, terminal mappings are generally stored in a file called <TT>termcap</TT>.
The termcap library, reportedly introduced with Berkeley UNIX, is a very important
addition to the system. Without it, many machines would not communicate well with
each other. For example, if you perform a fresh install of a Linux operating system
and do nothing to alter the <TT>TERM</TT> variable, it will be set to <TT>Linux</TT>.
If you then Telnet to a SPARCstation (or other machine that also has its default
<TT>TERM</TT> configuration), you will be unable to clear the screen with the well-known
command <TT>clear</TT>. This is because the two terminal emulation settings are incompatible.
Furthermore, if you try to execute a program such as <TT>PINE</TT>--which relies
on compatible terminal types--the program will exit on error, reporting that the
terminal is not supported. (SysV systems traditionally use <TT>terminfo</TT> as opposed
to <TT>termcap</TT>.)


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>CAUTION:</B></FONT><B> </B>Many distributions of UNIX have
	complete termcap listings, which sometimes contain hundreds of terminal emulations.
	If you are new to UNIX and are toying with the idea of altering your termcap entries,
	be extremely careful. You may end up with bizarre results. In some cases, what once
	looked like nicely formatted text may appear as strange, disjointed, scattered blocks
	of words that are largely illegible. Study the man page before fiddling with your
	<TT>termcap</TT> file. 
<HR>


</BLOCKQUOTE>

<P>Many different environmental variables can be set. These variables can strongly
influence how a remote machine will receive, process, and support your remote Telnet
connection. Thus, the Telnet protocol was designed to allow the passing of certain
environment variables at the time of the connection. As explained in RFC 1408:

<DL>
	<DD>Many operating systems have startup information and environment variables that
	contain information that should be propagated to remote machines when Telnet connections
	are established. Rather than create a new Telnet option each time someone comes up
	with some new information that they need propagated through a Telnet session, but
	that the Telnet session itself doesn't really need to know about, this generic information
	option can be used.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>To view RFC 1408 in its
	entirety, visit <A HREF="http://sunsite.auc.dk/RFC/rfc/rfc1408.html"><TT>http://sunsite.auc.dk/RFC/rfc/rfc1408.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>The recent Telnet security hole was based on the capability of a Telnet server
to receive, respond to, and authorize the passing of these environment variables.
Because this option was so prominent in the UNIX system, an incredible number of
platforms were vulnerable to this attack.</P>
<P>This vulnerability is more common than one would expect. In a rather engrossing
report, one firm, Novatech, posted the results of an actual security audit of a network
with 13 hosts. In it, the Telnet vulnerability appears, as do<I> 138 other holes</I>.
The most extraordinary thing is that the site had already been assessed as having
a clean bill of health, complete with a firewall. As Novatech's sample audit report
notes:

<DL>
	<DD>This is a copy of a actual attack report with definitions and possible rectifications
	of actual problems found. The network had a state of the art firewall installed and
	had been checked by CERT. As you can see there were many small problems and a number
	of larger ones as well. This was not the fault of the systems administration but
	of a mix that systems change and need constant attention and the lack of knowledge
	of how intruders gain access (a specialist field). We are able to check your system
	for nearly 390 different forms of access vulnerability all of which are Internet
	only type access.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference: </B></FONT>For those who have a &quot;let's
	wait and see&quot; attitude about security, I suggest that you go immediately to
	this site and view the results. They are astonishing. See the results of the audit
	at <A HREF="http://www.novatech.net.au/sample.htm"><TT>http://www.novatech.net.au/sample.htm</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>The line that reveals the Telnet environment option vulnerability reads as follows:</P>
<PRE><FONT COLOR="#0066FF">Dynamic Linker Telnet Vulnerability [High Risk]2
</FONT></PRE>
<P>This line reports that a Telnet vulnerability in the high risk category was found
(in the audit cited previously, this vulnerability was found on two hosts within
the same subnet). <TT>[High Risk]2</TT> refers to the level of risk the hole represents.
This is an extremely high risk vulnerability. Remember, this was found on a host
with a state-of-the-art firewall!</P>
<P>To understand the method, you must understand precisely what options can be passed
from the client to the server. One of these involves the passing of a custom <TT>libc</TT>.