From - Thu Oct 30 08:14:32 1997 Path: news.mitre.org!blanket.mitre.org!admiral!spock!news.apk.net!news.micro-net.net!uunet!in2.uu.net!news.mathworks.com!howland.erols.net!newsfeed.internetmci.com!207.69.200.61!mindspring!news.mindspring.com!usenet From: " Mark D. LaDue" Newsgroups: comp.security.misc Subject: How to Write Bad Java Security Software Date: Wed, 29 Oct 1997 19:29:48 -0600 Organization: MindSpring Enterprises Lines: 475 Message-ID: <3457E30A.C2C23CFA@mindspring.com> NNTP-Posting-Host: ip89.fort-worth2.tx.pub-ip.psi.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 30 Oct 1997 01:29:50 GMT X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5 sun4m) Apparently Finjan Software's Lawyers didn't appreciate my candid review of their SurfinShield tool, so now the Hostile Applets Home Page has a new home: ************************************************************** * * * For interesting and entertaining thoughts on Java Security * * visit the Hostile Applets Home Page at * * http://www.mindspring.com/~mladue/HostileApplets.html * * * ************************************************************** For the moment you can read my review at http://www.mindspring.com/~mladue/drowning.html Just in case it has to be moved again, you'll find it below in its entirety. Enjoy! Mark D. LaDue Drowning in the Surf: A Review of Finjan Software's SurfinShield 2.0 -------------------------------------------------------------------- by Mark D. LaDue 1. Introduction --------------- In the past two years the advent of executable content in World Wide Web applications has increased the risks of attack from traditional threats, such as Trojan horses and viruses, and has added new risks, such as hostile applets. Java and ActiveX technologies present overlapping sets of problems, and while there are third-party vendors who claim to offer solutions, a closer look at the products of the self-proclaimed "Leader in Java and ActiveX Security" reveals that their solutions can make matters worse. The following is a review of the problems suffered by Finjan Software's SurfinShield 2.0, a security tool written entirely in Java and advertised to protect the web browser and its master from hostile code. Once we have examined SurfinShield's failures, we then outline some of the lessons to be drawn from them. 2. Drowning in the Surf ----------------------- Since the release of the first Java Development Kit and Java-enabled web browsers almost a year and a half ago, there has been a perceived need for security tools to supplement the safeguards built into these products. Finjan Software, the self-touted "Leader in Java and ActiveX Security," has attempted to develop and market such tools. The author recently downloaded the evaluation version of Finjan Software's SurfinShield 2.0 for UNIX and subjected it to an array of hacker-style tests to assess its weaknesses. To do so, a non-privleged user was created as a crash test dummy on a Sun SPARCstation 5 running Solaris 2.5. In addition to the standard tools available on the platform, the dummy user had the Netscape Navigator 3.01 and Java Development Kit 1.1.1 set up in his home directory. SurfinShield's installation script, sfsinstall, had trouble handling this arrangement, and it failed irremediably to install under JDK 1.1.1 due to Java runtime errors. So the author reverted to JDK 1.0.2 and hacked sfsinstall until the installation of the product was successful. Probing and testing from a hacker's point of view then revealed that SurfinShield has enough enough holes in it to sink a battleship. It quickly takes on water and sinks, leaving the unfortunate user to drown in the surf. SurfinShield's candid list of "Known Bugs of this revision," which appears in the file README.txt, leads one to have serious doubts about the effectiveness of the tool. Since it tells us a great deal about the quality of the software and is, in fact, a typical list of problems faced by Java developers, we quote it here at length, grammatical errors and all [SS2R]: Known Bugs of this revision: ---------------------------- 1) Due to a bug in the Java environment, two applications cannot share access to the sound device. Therefore, from time to time, either SurfinShield or new Applets loaded into the system, may fail to play sound files. To avoid this problem, simply uncheck the "enable alert sounds" box in the settings window and SurfinShield will refrain from using the sound device. 2) The Java environment of the browser, does not allow SurfinShield to eliminated any sub-windows of the Applets from the system in the middle of the session. SurfinShield will still prevent the applet from performing a security breach function (such as send an e-mail) and will add it to the Suspicious Applets Database. 3) The "Cancel" button in the Suspicious Applets Database does not cancel changes done by the user. All changes will apply and will show on the list unless specifically deleted by the user. 4) If the browser is invoked automatically from the startup folder (as is the case with SurfinShield), bringing up a home page with an applet, SurfinShield may fail to recognize the existence of the browser in the system. When this happens, SurfinShield will not show any applet on it's screen and will not provide Java protection to the browser environment. To avoid this problem, simply make sure SurfinShield is already up and running before accessing a Java enabled web page for the first time. 5) Invoking the "Settings" window before any browser is up, will prevent the "system information" tab from showing the "Java Vendor" and the "Browser Name" for the remainder of the session. 6) Wrong entries (such as illegal URLs) may be entered by the user and added to the Suspicious Applets Database. 7) When the "Auto Kill Suspicious Applets" is not checked (in the "Settings" window) and facing multiple applets causing multiple security exception at the same time, SurfinShield may eventually fail to handle all security exception successfully. 8) Uninstall fails to eliminate itself (the uninstall.exe program). Items 3, 6, and 8 are nothing short of comical. While item 4 is a serious flaw, one might be able to work around it, but item 7 offers no such possibility. One suspects from the first item that SurfinShield may not be able to defeat the NoisyBear (a Java applet that plays annoying sounds that cannot be eliminated), and the second item reveals that SurfinShield will not be able to shut down a "big windows" denial-of-service attack. Thus it appears that SurfinShield is already dead in the water. As if all of this were already not enough, if one is foolhardy enough to want to purchase the tool, the price may be quite high. For buried near the bottom of the sfsinstall, the installation script, are the following lines of code [SS2s]: # If this is a purchase version, run Register: if ($versionType != EVAL) then /usr/openwin/bin/xhost + $sfsInstallDir/register.exe $sfsInstallDir doNotShow if ($status != 0 ) then echo "Failed to run register.exe. Please run register.exe from installation directory." #goto abort endif endif Thus if one wants to purchase SurfinShield for a SPARCstation, Finjan politely turns off all access control to its X server and leaves it off, exposing it to a multitude of attacks. A company selling computer security tools should know better than this. [Incidentally, when the author downloaded the evaluation version of SurfinShield, he observed quite a number of directories at ftp.finjan.com owned and writable by the user "ftp," the standard login name for anonymous ftp. Further inspection revealed various directories named "warez" and several oddly named directories containing JPEG and GIF images. Thus ftp.finjan.com may have been serving as a repository for pornography and pirated software. Again, a company whose business is supposed to be computer security should know better.] From Finjan's list of "Known Bugs of this revision," one suspects that SurfinShield 2.0 is unreliable and ineffective. How then can the demo at http://www.finjan.com/ appear to work so well? (Note: The demo points one's browser at the author's Hostile Applets Home Page, which has links to hostile applets that can be downloaded.) The answer can be found by exposing one of Finjan's misleading claims, that of keeping a "Suspicious Applets database." Instead of keeping such a database, what SurfinShield actually keeps, in the file config/Susp.sfs, is a list of Java class names and some URLS at which they reside. Consequently, SurfinShield's "prevent downloading of suspicious applets" feature offers no protection against attacks from even known hostile applets when those applets have URL's and/or class names differing from those already on SurfinShield's list. Simple tests on hostile applets confirm this observation. Finjan's web site demo works precisely because it points one's browser at URL's that are already known to contain hostile applets, and it then refuses to download the applets based only upon their URL's, not their content. Obviously this is a very poor defense against hostile applets from parts unknown. But even if SurfinShield were to keep a database of the applets themselves, such a database would still provide very little protection. For the same attacks can be carried out in numerous ways, all of which would have to be known in advance. The unfortunate user would still be left with the unpleasant prospects of relying on Finjan's database and learning from experience. Apparently it never occurred to the folks at Finjan to combat hostile applets by detecting their malicious effects and stopping them dead in their tracks when they misbehave. To show that this idea is feasible, the author spent a week developing a tool which runs from Netscape's Java Console and defeats all known hostile applets by monitoring their behavior and effectively annihilating them when they violate security policies set by the user. Thus the failure of SurfinShield to offer even minimal protection is all the more reprehensible. The fact that a perfectly harmless applet such as Sun's "Hang Duke" appears in the initial database supplied by Finjan (with the entry http://www.javasoft.com/applets/applets/Hangman/Hangman) casts further doubt on the tool [SS2S]. But Sun's venerable applet does serve to illustrate this serious SurfinShield shortcoming. Unfortunately for SurfinShield, "www.javasoft.com" and "java.sun.com" are aliases for "web2.javasoft.com" (when this was written). So a browser pointed at the URL http://www.javasoft.com/applets/applets/Hangman/ actually winds up downloading the applet from the URL http://java.sun.com/applets/Hangman/, and SurfinShield, even operating in its strongest mode, fails to prevent this applet from downloading. Almost remarkarbly, SurfinShield's buttons to "kill applet" and "kill all applets" do at first seem to work - clicking either of them does seem to kill Sun's malicious little Hangman and save their mascot Duke. But keep Netscape 3.01 pointed at the Hangman's URL, do nothing but wait a few seconds, and the applet will initialize itself and appear once again with a "bong" in SurfinShield's log window. This can be done repeatedly, so had Sun hidden some malicious code in the init() method of the hostile Hangman, SurfinShield would have been pleased to let it run repeatedly. Moreover, the act of closing and re-opening the browser window starts the initialized applet running again, and the same seems to hold true for an arbitrary applet. Thus Sun's friendly little Hangman has caught Finjan with trousers down and Duke exposed. After this example, the reader can probably guess the results of testing SurfinShield 2.0, with its strongest defenses set, against known hostile applets downloaded from URL's not in the file config/Susp.sfs: SurfinShield does not prevent them from being downloaded. And when the user happens to notice a hostile applet running in his browser and is able to instruct SurfinShield to kill it, the applet can still initialize and restart itself without the user reloading it or revisiting its web page. Two examples which relate to items 1 and 2 of Finjan's "Known Bugs of this revision" should suffice to illustrate SurfinShield's impotence. NoisyBear.java is a hostile applet which displays a picture of a bear in one thread and plays an annoying sound in another thread. The sound is started by the method java.applet.AudioClip.loop() and cannot be stopped without killing the browser. When this applet was downloaded from a URL not listed in SurfinShield's database, then of course SurfinShield did not prevent it. Using either of SurfinShield's "kill applet" or "kill all applets" buttons did kill the graphics thread of the NoisyBear, but in trying to handle the audio portion of the applet, SurfinShield got a segmentation violation and died, leaving the browser running and beating the NoisyBear's drum. The problem was predictable from item 1 of Finjan's "Known Bugs," though one should be suspicious of the claim that the fault lies with JavaSoft, not Finjan. TripleThreat.java is a hostile applet which squanders resources, plays an annoying sound ad infinitum, and pops up million-by-million pixel black windows in an infinite loop. SurfinShield was powerless to prevent the applet from downloading from an unknown URL. Once the "big windows" attack had started, SurfinShield was unable to stop it. Though it has a feature (assuming that it works) of killing applets which throw security exceptions, TripleThreat's code is all perfectly legal Java, and it doesn't throw runtime errors, at least not until long after its damage is already done. Thus this advertised feature of SurfinShield can fail. Moreover, even if SurfinShield could halt the applet, it would be unable to clean up the big windows that were opened, as was mentioned in item 2 of the "Known Bugs," and the user would have to resort to other means (none of which are especially palatable) to do so. By now the reader might be inclined to agree that SurfinShield 2.0 is not worth its price tag, but perhaps some patient, tolerant, and generous soul would find it acceptable as freeware. Since SurfinShield is written entirely in Java, this is quite easily arranged. The evaluation version that one downloads over the Internet has a 30 day evaluation license. When sfsinstall, SurfinShield's installation script, installs the software, it allows the zip application to call attention to a certain Java class file, SFped.class. One can examine this file using either Sun's javap disassembler or the Mocha decompiler and see that the original date of the evaluation license is hard-coded into the file. The output of either javap or Mocha allows one to arrange a non-expiring evaluation license in three easy steps: (a) Use this little program called SFped.java: /* SFped.java */ import java.util.Date; public class SFped { public Date ped; public SFped() { ped = new Date(); ped.setDate(ped.getDate() - 1); } } (b) Compile it to obtain SFped.class, and place it the SurfinShield directory along with SurfinShield.zip. (c) Update SurfinShield.zip with the following command: zip -u -n ".class" SurfinShield.zip SFped.class SurfinShield will now run as before, and its splash screen will always report that the evaluation license has 29 days before it expires. Of course the author does not recommend doing this for the same reason that he does not recommend swimming with a ship's anchor attached to your neck. The best course of action for anyone unfortunate enough to have installed SurfinShield is to delete the whole software package and reinstall an untainted browser from scratch. 3. Lessons From SurfinShield ---------------------------- The sad case of Finjan's SurfinShield illustrates a number of problems that developers of security tools for World Wide Web applications will have to face. Bearing in mind SurfinShield's many failures, we may list some of the key ingredients necessary for improving desktop defenses: 1. The need for a wrapper program - Several of SurfinShield's problems (see items 1, 4, and 5 from the list of "Known Bugs") stem from a lack of coordination between SurfinShield and the browser. A wrapper program could better control and coordinate both the browser and any additional security tools deployed to defend it. 2. The need for integrity checking - It is all too easy to hack SurfinShield and install one's own perpetual license. It would be just as easy for hostile code, even an attack applet, to modify SurfinShield and throw a system wide open to further abuse. An integrity checking mechanism could be used to detect and then thwart such attacks should other mechanisms fail to prevent them. 3. The need for improved resource monitoring and logging - Security policies should also be set in terms of resource allocation and usage, and improved security tools should be able to log and shut down any applications found in violation of those policies. A list of URL's known to contain hostile code can also be kept, but it should be recognized that this task is more related to logging and is not acceptable as a main line of defense. 4. The need for minimizing the reliance on Java for defense - Java is new and still has many problems to be discovered and worked out. Security tools relying exclusively on Java will be weak where the language is weak. Though it is easier and may be more profitable to develop "write once, run everywhere" tools in Java, such tools are susceptible to "write once, run everywhere" cross-platform attacks. Security tools written in Java are also susceptible to decompilation and analysis by hackers and business competitors. It would be wiser to have only limited portions of a tool, such as those having a direct interface with the Java Runtime, written in Java. 5. The need for caution in modifying or replacing browser code - Some of SurfinShield's problems arise from its wholesale and heavyhanded modification of the browser's Java classes. It would be wiser to minimize such changes and limit them to the addition of further security hooks. Otherwise there is an increased risk of introducing new security holes in the browser. 6. The need for other Java security hooks - The AppletClassLoader and AppletSecurity classes can be modified safely to include other security features such as URL access control, restricted port access, additional class file verification, and resource limits to preclude denial-of-service attacks. 7. The need for defending Java classes from decompilation - Any portions of a security tool written in Java need defense from easy decompilation via standard and non-standard methods. Of course one can always disassemble Java code and inspect it, but obfuscation techniques would force hackers, business competitors and even cheating tools users to read and understand Java programs at the assembly level, a much more formidable, though not an insurmountable, hurdle to overcome. Third parties who seek to improve the security of web browsers by grafting on additional features would do well to study SurfinShield's numerous failures. 4. References --------------- [SS2R] Finjan Software Ltd., Netanya, Israel. README.txt in SurfinShield 2.0 (UNIX Version). [SS2s] Finjan Software Ltd., Netanya, Israel. sfsinstall in SurfinShield 2.0 (UNIX Version). [SS2S] Finjan Software Ltd., Netanya, Israel. Susp.sfs in SurfinShield 2.0 (UNIX Version).