ch30.htm

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

special functions common to that library. For example, if you include <TT>crypt()</TT>
in your program, you may call the encryption routines common to the <TT>crypt</TT>
library from anywhere within the program. This program is then said to have <TT>crypt</TT>
within it and, therefore, it has cryptographic capabilities.</P>
<P>Java was such the rage that Netscape Communications Corporation included Java
within certain versions of its flagship product, Navigator. That means supported
versions of Netscape Navigator were Java enabled and could respond to Java programming
calls from within a Java applet. Thus, Java applets could directly affect the behavior
of Navigator.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>The Java runtime environment incorporated
	into the code of the Netscape Navigator browser (and many other browsers) is standard
	and totally distinct from the Java runtime engine provided with the Java Development
	Kit (JDK). 
<HR>


</BLOCKQUOTE>

<P>Because Navigator and Internet Explorer are the two most commonly used browsers
on the Internet, an entire class of users (on multiple platforms) could potentially
be affected by Java security problems. Some of those platforms are

<UL>
	<LI>Windows, Windows 95, and Windows NT<BR>
	<BR>
	
	<LI>Any supported flavor of UNIX<BR>
	<BR>
	
	<LI>Macintosh
</UL>

<H4><FONT COLOR="#000077"><B>What Was All the Fuss About?</B></FONT></H4>
<P>The majority of earth-shaking news about Java security came from a handful of
sources. One source was Princeton University's Department of Computer Science. Drew
Dean, Edward W. Felten, and Dan S. Wallach were the chief investigators at that location.
Felten, the lead name on this list, is an Assistant Professor of Computer Science
at Princeton University since 1993 and a one-time recipient of the National Young
Investigator award (1994). Professor Felten worked closely with Dean and Wallach
(both computer science graduate students at Princeton) on finding holes unique to
Java.</P>
<P>Holes within the Java system are not the Felten team's only claim to fame, either.
You may recall a paper discussed earlier in this book on a technique dubbed <I>Web
spoofing</I>. The Felten team (in conjunction with Dirk Balfanz, also a graduate
student) authored that paper as well, which details a new method of the <I>man-in-the-middle</I>
attack.</P>
<P>In any event, weaknesses within the Java language that were identified by this
team include the following:

<UL>
	<LI>Denial-of-service attacks could be effected in two ways: first, by locking certain
	internal elements of the Netscape and HotJava browsers, thereby preventing further
	host lookups via DNS; second, by forcing CPU and RAM overutilization, thus grinding
	the browser to a halt. Further, the origin of such an attack could be obscured because
	the detrimental effects could be delayed by issuing the instructions as a timed job.
	Therefore, a cruiser could theoretically land on the offending page at noon, but
	the effect would not surface until hours later.<BR>
	<BR>
	
	<LI>DNS attacks could be initiated where the browser's proxies would be knocked out,
	and the system's DNS server could be arbitrarily assigned by a malicious Java applet.
	This means that the victim's DNS queries could be re-routed to a cracked DNS server,
	which would provide misinformation on hostnames. This could be a very serious problem
	that could ultimately result in a root compromise (if the operator of the victim
	machine were foolish enough to browse the Web as <TT>root</TT>).<BR>
	<BR>
	
	<LI>At least one (and perhaps more) version of Java-enabled browsers could write
	to a Windows 95 file system. In most all versions, environment variables were easily
	culled from a Java applet, Java applets could snoop data that many feel is private,
	and information could be gathered about where the target had been.<BR>
	<BR>
	
	<LI>Finally, Java suffered from several buffer overflow problems.
</UL>

<P>Public reaction to the findings of the Felten team was not good. This was especially
so because the researchers wrote that they had advised Sun and Netscape of the problems.
The two giants responded with a fix, but alas, many of the original problems remained,
opened by other avenues of attack.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The Felten team's paper,
	titled &quot;Java Security: From HotJava to Netscape and Beyond,&quot; can be found
	on the Web at <A HREF="http://www.cs.princeton.edu/sip/pub/secure96.html"><TT>http://www.cs.princeton.edu/sip/pub/secure96.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>JavaSoft (the authoritative online source for Java developments) responded to
these reports promptly, although that response did not necessarily indicate a solution.
In one online advisory, the folks at JavaSoft acknowledge that hostile Java applets
have been written (they even gave a few links) and suggest that work was underway
to correct the problems. However, the advice on what to do if such applets are encountered
offers users very little sense of security. For example, when confronted by a Java
applet that entirely blew away your browser, the advice was this:

<DL>
	<DD>...one way to recover from this applet is to kill the browser running on your
	computer. On a UNIX system, one way to accomplish this is to remotely log into your
	computer from another computer on your local network, use <TT>ps</TT> to find the
	process ID that matches the hijacked browser's process ID, and issue a <TT>kill -9
	PID</TT>.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>JavaSoft's advisory can
	be found at <A HREF="http://java.javasoft.com/sfaq/denialOfService.html"><TT>http://java.javasoft.com/sfaq/denialOfService.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>Killing your browser is hardly a method of recovering from an attack. For all
purposes, such a denial-of-service attack has effectively incapacitated your application.</P>
<P>It was determined that users running Java-enabled browsers were posing risks to
those networks protected by firewalls. That is, Java would flow directly through
the firewall; if the applet was malicious, firewall security could be breached then
and there. Crackers now have lively discussions on the Internet about breaking a
firewall in this manner. And, because Java shares so many attributes with C++ (which
may be thought of as a superset of C), the programming knowledge required to do so
is not foreign terrain to most talented crackers.</P>
<P>Many proponents of Java loudly proclaimed that such an attack was impossible,
a matter of conjecture, and knee-jerk, alarmist discussion at best. Those forces
were silenced, however, with the posting of a paper titled &quot;Blocking Java Applets
at the Firewall.&quot; The authors of this paper demonstrated a method through which
a Java applet could cajole a firewall into arbitrarily opening otherwise restricted
ports to the applet's host. In other words, an applet so designed could totally circumvent
the basic purpose (and functionality) of the firewall, full stop. Thus, in addition
to other weaknesses that Java had already introduced, it was also found to be an
ice pick with which to stab through a firewall.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>&quot;Blocking Java Applets
	at the Firewall,&quot; by David M. Martin Jr., Sivaramakrishnan Rajagopalan, and
	Aviel D. Rubin, can be found on the Web at <A HREF="http://www.cs.bu.edu/techreports/96-026-java-firewalls.ps.Z"><TT>http://www.cs.bu.edu/techreports/96-026-java-firewalls.ps.Z</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>Although many of these matters have been fixed by Sun and JavaSoft, some problems
still remain. Further, many individuals are still using older versions of the Java
runtime and development kits, as well as older versions of Java-enabled browsers.
However, in fairness, JavaSoft and Sun have resolved many of the problems with this
new language.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>To get a closer view
	of JavaSoft and Sun's fixes (by version number), check out <A HREF="http://www.javasoft.com:80/sfaq/index.html"><TT>http://www.javasoft.com:80/sfaq/index.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>For the average user, hostile Java applets (at least, those produced thus far
by the academic community) can produce no more than minor inconveniences, requiring
reboot of the browser or the machine. However, for those who work in information
security, Java has an entirely different face. Any unwanted element that can slip
through a firewall is indeed a threat to security. If you are a system administrator
of an internal network that provides partial or full access to the Internet, I advise
you to forbid (at least for the moment) the use of browsers that are Java enabled
or enforce a policy that users disable Java access.</P>
<P>The Java controversy teaches us this: The Internet is not secure. Moreover, programming
languages and techniques deemed secure today are almost invariably found to be insecure
tomorrow. In a recent New Riders book on Internet security (<I>Internet Security:
Professional Reference</I>), the authors discuss the wonderful features of Java security
(there is even a section titled &quot;Java is Secure&quot;). I am certain that at
the time the book was written, the authors had no idea about the security flaws of
Java. So carefully consider this point: Any new technology on the Internet should
be viewed with suspicion. It is wise to remember that even today, holes are occasionally
found in Sendmail, many years after its introduction to the network.</P>
<P>Perhaps the most threatening element of Java is this: We have not yet seen the
cracking community work with it. Traditionally, cracking is done using garden-variety
tools that have been around for years, including C and Perl. However, it is clear
that Java could be used in information warfare as a tool to disable machines or otherwise
disrupt service.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>For an interesting viewpoint
	on the use of Java in information warfare, check out Mark D. LaDue's article, &quot;Java
	Insecurity,&quot; scheduled to appear in the Spring 1997 issue of the <I>Computer
	Security Institute's Computer Security Journal</I>. The article can be found on the
	Web at <A HREF="http://www.math.gatech.edu/~mladue/Java_insecurity.html"><TT>http://www.math.gatech.edu/~mladue/Java_insecurity.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>I should point out here that there have been no recorded instances of Java security
breaches in the wild. All the attack schemes developed and tested have been cultivated
in either academic or corporate research environment. Furthermore, for the average
user, Java security is not a critical issue. Rather, it is within the purview of
system administrators and information- security experts that this information is
most critical. Actual dangers to the PC computing communities are discussed later
in this chapter when I treat Microsoft's ActiveX technology at length.</P>
<P>To learn more about Java security, there are a number of papers you must acquire.
Many of these papers are written by programmers for programmers, so much of the material
may seem quite technical. Nevertheless, the average user can still gain much important
information from them.</P>
<P><B>Java Security: Weaknesses and Solutions.</B> Jean-Paul Billon, Consultant VIP
DYADE. This document is significant because it is one of the latest treatments of
the Java security problem. Updates on this document extend into December 1996. This
is an invaluable resource for programmers as well as the general public. The information
contained within this document addresses weaknesses within the runtime system as
well as the language itself. More importantly, the document gives two practical examples
and proposes some possible solutions. Excellent.

<UL>
	<LI><A HREF="http://www.dyade.fr/actions/VIP/JS_pap2.html"><TT>http://www.dyade.fr/actions/VIP/JS_pap2.html</TT></A>
</UL>

<P><B>Low Level Security in Java.</B> Frank Yellin. This paper is one of the first
papers to address Java security. It is an important paper, particularly for programmers
and system administrators, because it describes the basic characteristics of the
Java language and the security considerations behind it.

<UL>
	<LI><A HREF="http://www.javasoft.com/sfaq/verifier.html"><TT>http://www.javasoft.com/sfaq/verifier.html</TT></A>.
</UL>

<P><B>Java Security.</B> Joseph A. Bank (MIT). This paper is a must-read for anyone
who wants to learn about Java security. It is a well-written and often easily read
analysis of Java and its security features. Most importantly, the paper takes the
reader through stages, making it easier for the newcomer to programming to understand
the features of Java.

<UL>
	<LI><A HREF="http://www.swiss.ai.mit.edu/~jbank/javapaper/javapaper.html"><TT>http://www.swiss.ai.mit.edu/~jbank/javapaper/javapaper.html</TT></A>
</UL>