ch22.htm

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

<P>Although I have no hard evidence, I would suggest that the percentage of crackers
who can obtain root on a given box or architecture is pretty high. The percentage
who can do it on a UNIX system is a more or less static value, I would imagine. Much
is known about UNIX, and the reporting lists are quite informative (the same might
be said for Novell NetWare). Nonetheless, that number with respect to NT is changing
rapidly in an upward direction. I suspect that within a year, that number will be
as high or higher than percentages in other categories.</P>
<P>Cracking root (at least on UNIX) occurs far more commonly through advanced programming
techniques than through cracking the <TT>/etc/passwd</TT> file. Root operators know
a little something about security and generally make their own passwords extremely
difficult to crack (and they should). Experienced system administrators have probably
cracked their own <TT>passwd</TT> file a dozen times. They will likely create a password
that takes weeks or even months to crack. Thus, employing a password cracker is probably
a waste of time.</P>
<P>If, on the other hand, programs located on the disk are run as root processes,
you might be able to crack root quickly and easily. It is not necessary that you
log in as root, only that you gain root privileges. This most often comes through
the exploitation of a buffer overflow.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>TIP:</B></FONT><B> </B>You can get a better view of buffer
	overflows and other programming errors and weaknesses in Chapter 30, &quot;Language,
	Extensions, and Security.&quot; 
<HR>


</BLOCKQUOTE>

<P>Exploits of this nature are posted regularly to many mailing lists and newsgroups.
As long as the cracker knows how to run a compiler, these postings can be clipped
and pasted directly to a text editor, compiled, and executed with minimal effort.
After the cracker has made a test run on a similar platform (for example, on a SolarisX86
to simulate a possible Solaris hole, or ideally, Solaris to Solaris), he is ready.
The compromise will take only seconds.</P>
<P>In most cases, the cracker need not even keep up with the times. Many older holes
still work on systems that have not been adequately secured. I hate to say it, but
most system administrators do not spend their time scouring mailing list archives
for possible holes within the system. Too bad.
<H2><FONT COLOR="#000077"><B>Root Might Be a Thing of the Past</B></FONT></H2>
<P>As incredible as it may seem, root might soon be an outdated concept. Many of
the security problems that emerge on the Internet are due to the existence of this
privileged account. Studies are underway to seek alternatives. The folks at Bell
Labs have actually implemented such a system called Plan 9 (see Chapter 21, &quot;Plan
9 from Bell Labs&quot;). As explained in the publicly available documentation on
Plan 9:

<DL>
	<DD>Plan 9 has no super-user. Each server is responsible for maintaining its own
	security, usually permitting access only from the console, which is protected by
	a password. For example, file servers have a unique administrative user called adm,
	with special privileges that apply only to commands typed at the server's physical
	console. These privileges concern the day-to-day maintenance of the server, such
	as adding new users and configuring disks and networks. The privileges do not include
	the ability to modify, examine, or change the permissions of any files. If a file
	is read-protected by a user, only that user may grant access to others.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The above paragraph is
	excerpted from &quot;Plan 9 from Bell Labs,&quot; a paper by the core members of
	the Plan 9 team. Those members are Rob Pike, Dave Presotto, Sean Dorward, Bob Flandrena,
	Ken Thompson, Howard Trickey, and Phil Winterbottom. This paper can be found online
	at <A HREF="http://plan9.bell-labs.com/plan9/doc/9.html"><TT>http://plan9.bell-labs.com/plan9/doc/9.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>Plan 9 is an interesting idea, and will surely eliminate many of the security
problems now associated with the root account. Nonetheless, there are other problems
that this new system could create. One revolves around this statement (made in &quot;Plan
9 from Bell Labs&quot;):

<DL>
	<DD>If a file is read-protected by a user, only that user may grant access to others.
</DL>

<P>If this policy was enforced in the most absolute sense, malicious users might
present a problem. For example, if a malicious user's materials were read-only to
the rest of the world, or if even more stringent controls were placed on access of
the files, it might present a situation where the only viable answer to a malicious
user is to freeze or possibly destroy his account. This is a nice solution, but an
irritating one, all the same.</P>
<P>This notwithstanding, I believe the Plan 9 model is far more secure not only because
it eliminates root but because of the unique manner in which it implements distributed
computing. As you might remember from Chapter 21, Plan 9 uses both a CPU and a file
server. The user is saddled with something that is a cross between an X terminal
and a PC. Because the file server remains isolated, and because nearly all resources
are distributed and the permissions set on that file server are automatically set
in a dynamic fashion (for example, as files and processes change or are created),
there is a good chance that a systemwide compromise of Plan 9 is nearly impossible.</P>
<P>Nonetheless, there might be other security implications of Plan 9. For example,
because you can tap a resource from any type of file system, remote or otherwise,
and because these resources can be attached to local directories to act and appear
as though they are local, there is the possibility that Plan 9 might ultimately emerge
as a tool capable of compromising other operating systems. This is hard to say, however,
because there is relatively little documentation available about tests in this area.
I haven't tried to make such a test. Yet.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>The developers of Plan 9 thought
	big. By that, I mean they thought in terms of an operating system that could support
	a total number of users in the tens of thousands. I can see where it will ultimately
	be used in WAN settings. 
<HR>


</BLOCKQUOTE>

<H2><FONT COLOR="#000077"><B>Root on Other Operating Systems</B></FONT></H2>
<P>UNIX is not the only system that uses root. Microsoft Windows NT also uses a version
of root, called <I>administrator</I>. Similarly, Novell implements a version called
<I>supervisor</I>. In all cases, root's power and obligations are the same: They
involve system management. Both systems provide for almost identical control of access
permissions (however, I believe NetWare is a bit more comprehensive).
<H2><FONT COLOR="#000077"><B>The Cracker Who Is Root</B></FONT></H2>
<P>I should explain here that <I>having</I> <I>root</I> is not an uncommon condition.
Root can be had for the price of a few dollars. For example, you can install Linux
or FreeBSD on a PC and instantly be root<I> on that particular box.</I> Some administrators
might scoff at this, thinking it matters little if a cracker establishes a box on
which he or she is root. But this does give the cracker some small advantages:

<UL>
	<LI>It gives the cracker access to some native applications in the operating system
	environment that he would not otherwise have. I have mentioned that having root status
	on a UNIX box provides the cracker with many tools that are not available on other
	platforms.<BR>
	<BR>
	
	<LI>Security specialists often write commercial-grade packages and release them on
	the Internet free of charge. In some instances, this is purely a philanthropic act,
	a contribution to network security by people with the ability to improve it (SATAN
	is one such program). In other instances, a product might be provided free to noncommercial
	users, but might be restricted to use on a localhost box. SAFESuite by ISS is an
	example of one such utility. Because such tools can be a threat to Internet security
	if in the wrong hands, developers often design them so that only root can run the
	software. This poses a natural barrier to many crackers. For example, they cannot
	simply load the software onto a workstation at a university and expect the software
	to run. Also, although many free versions of UNIX can be acquired for next to nothing,
	the cracker also needs to come by the hardware. That means impoverished crackers
	can't easily set up their own equipment and call themselves root.<BR>
	<BR>
	
	<LI>The cracker gets an opportunity to learn how logging works. Because he is root,
	he can attack his machine and analyze the results. He can also try out various types
	of security software and attempt to circumvent those utilities.<BR>
	<BR>
	
	<LI>The cracker who is root learns the fundamentals of system administration. This,
	more than any other experience, offers valuable knowledge and insight into system
	security.
</UL>

<P>There are also less important advantages, such as being able to manipulate one's
own mail and news server, and provide networking services to other crackers in the
void. However, these advantages are negligible from an educational point of view.
The only real challenge involved there is that of preventing individuals who do have
access to the box from destroying it.
<H2><FONT COLOR="#000077"><B>Beware of Root</B></FONT></H2>
<P>If you are a cracker, you will need to beware. Root operators are very testy.
If they suspect you of wrongdoing, you have problems. This brings us to an important
issue: Root is always a human being. How that human being deals with you differs
case by case.</P>
<P>Crackers routinely position themselves in direct opposition of root, primarily
because the relationship between these two sets of people is assumed to be adversarial.
In fact, the relationship is adversarial, but that does not necessarily mean a state
of war. Many system administrators revel in stories about cracked networks. As long
as that network is not their own, such stories are consuming and highly informative.
One almost gets the feeling that some system administrators carry a recessive cracker
gene, but manage to find a suitable (and constructive) outlet for this darker side
in testing the security of their own network. In fact, you could say that in order
to maintain a secure network, one has to have a little cracker sense.</P>
<P>Nonetheless, contrary to what many might think, root people are often what I would
characterize as very hip. Their position demands great responsibility, which they
generally shoulder alone. Thus, one might say that root people exist in their own
world; within it, they are omnipotent (or at least, they initially appear that way).
To be a good system administrator, you need more than good toolsmithing skills or
a solid knowledge of the operating system. You must have a certain level of humanity
and good judgment. In my experience, most system administrators will tolerate a little
skullduggery before they freeze an errant user's account. This courtesy is extended
not because they favor crackers, but because most system administrators have a fundamental
sense of fair play.</P>
<P>That said, beware of root. Few individuals are more apt to persevere than a system
administrator whose network has been compromised. They might hunt you down across
continents, or might simply fly from California to North Carolina, armed with some
cell telephone scanning tools (as in the Shimomura case). In one instance, a 75 cent
error prompted a now famous system administrator (Clifford Stoll) to track down and
expose an entire espionage ring centered in Germany. The Cuckoo's Egg: Clifford Stoll,
an astronomer, conducted research at Lawrence Berkeley Laboratory (LBL) in California.
During his tenure there, Stoll assumed responsibility for management of the network
(Stoll has in fact been using the Internet since 1975) and was assigned to the task
of discovering the source of a 75 cent accounting error. His investigation ultimately
revealed that someone had gained unauthorized access to the local network. Rather
than immediately deny the unauthorized user access, he allowed the cracker to continue
these intrusions. Stoll ultimately determined that the cracker was using the LBL
network as a laun-ching point to crack systems located in the MILNET hierarchy. (MILNET
is a defense-related grouping of networks, distinct from the rest of the Internet.)
Stoll determined that the cracker--based in Germany--was stealing important defense-related
information. Stoll finally enlisted the help of American and German intelligence
agencies (who were not initially willing to listen to his suspicions). It turned
out that the cracker was part of a ring that was stealing U.S. defense information
and selling it to the Soviets. The story became an Internet legend, second only to
the Internet Worm. For more information, pick up a copy of Stoll's book, <I>The Cuckoo's
Egg </I>(Doubleday, 1989), which records the events in meticulous detail.
<H2><FONT COLOR="#000077"><B>Summary</B></FONT></H2>
<P>This chapter clears up a few things about root. This is important because in the
chapters that follow, I discuss various ways to attack the root account and otherwise
obtain root access. The following points have been made:

<UL>
	<LI>Root refers to anyone who has system administrator status.<BR>
	<BR>
	
	<LI>This status is usually issued on a box-by-box basis. For each box on a UNIX network,
	there is a root. For each NT box, there is an administrator.<BR>
	<BR>
	
	<LI>Root sets all file and directory permissions that are not automatically set by
	the operating system at the time of install.<BR>
	<BR>
	
	<LI>These permissions either grant or deny users (and groups) read, write, or execute
	access privileges.
</UL>

<P><A HREF="../ch23/ch23.htm">Chapter 23</A>, &quot;An Introduction to Breaching
a Server Internally,&quot; addresses some issues regarding crackers and how they
obtain root access.</P>
<CENTER>
<P>
<HR>
<A HREF="../ch21/ch21.htm"><IMG SRC="../button/previous.gif" WIDTH="128" HEIGHT="28"
ALIGN="BOTTOM" ALT="Previous chapter" BORDER="0"></A><A HREF="../ch23/ch23.htm"><IMG
SRC="../button/next.gif" WIDTH="128" HEIGHT="28" ALIGN="BOTTOM" ALT="Next chapter"
BORDER="0"></A><A HREF="../index.htm"><IMG SRC="../button/contents.gif" WIDTH="128"
HEIGHT="28" ALIGN="BOTTOM" ALT="Contents" BORDER="0"></A> <BR>
<BR>
<BR>
<IMG SRC="../button/corp.gif" WIDTH="284" HEIGHT="45" ALIGN="BOTTOM" ALT="Macmillan Computer Publishing USA"
BORDER="0"></P>

<P>&#169; <A HREF="../copy.htm">Copyright</A>, Macmillan Computer Publishing. All
rights reserved.
</CENTER>


</BODY>

</HTML>