10.7 Protecting Yourself from Malicious Java Code | Malicious Mobile Code: Virus Protection for Windows (OReilly Computer Security)


Team-Fly

	Malicious Mobile Code: Virus Protection for Windows By Roger A. Grimes Slots : 1
	Table of Contents

	Chapter 10. Malicious Java Applets

10.7 Protecting Yourself from Malicious Java Code

The following sections discuss several things you can do to protect your system against hostile Java code, starting with those recommendations anyone can perform, and ending with methods reserved for the more experienced user .

10.7.1 Total Security: Disable Java

If you are in an environment that demands total security, turn off all automatic executable content, including Java, in the Internet Security zone. This can be done in Internet Explorer by choosing Tools Internet Options Security CustomLevel Java DisableJava.

You may consider removing all Internet access. In an environment needing the highest security, it's hard to justify any Internet access. There are too many working exploits. There is still a steady stream of exploits coming out from the world of executable content. The Java sandbox has been compromised at least a dozen times. Although all of those have been in research labs, who's to say that a big hole hasn't been discovered by a hacker ready to use it around the world? Some of the more recent holes discovered did not take a "rocket scientist" to figure out. Some of them are scarily easy once you know how. If you have to have a totally secure environment, disable the Internet. Weigh your potential costs against the benefits.

10.7.2 Run Only Trusted Java

Nothing can beat not running malicious applets in the first place. Start now and promise never to run untrusted code again. If you run a Java-enabled web or file server, disable the ability of servlets to install themselves from untrusted sources. Also, remember that any plug-in increases the risk that your system can be compromised.

10.7.3 Use an Antivirus Scanner

Although antivirus scanners can recognize many malicious Java applets, if there is a big weakness with regular antivirus scanners , it is with their ability to reliably recognize previously unknown malicious Java code. Other products, like Finjan's SurfinGate , are built explicitly to handle browser-downloaded content and have had more protection success. I'll cover it in more detail in Chapter 14.

10.7.3.1 Firewalls

There are many firewalls on the market today that try to prevent malicious code from entering your network. I'll cover intelligent scanning firewalls in more detail in Chapter 14.

10.7.4 Configure Stronger Browser Java Security

Internet Explorer allows customized Java security. In most cases, it's enough to use the default Java security settings, but you may want to review your settings. Often, I visit clients who have accidentally lowered their browser's security settings without really understanding what they did.

10.7.4.1 Internet Explorer Java security

Internet Explorer has four security zones (Internet, Local Intranet, Trusted Sites, and Restricted Sites), and within each zone, Java safety can be set to High, Medium, Low, or Customized. The Customized option allows a user to define whether or not to allow a particular type of local system access depending on whether the Java applet is signed or not. Each security zone can be set to a particular level of Java security. Then what Java security is applied against an incoming applet is determined by whether or not the applet is signed and what security zone the applet arrives from. To review and change your Internet security zone settings, from within Internet Explorer, choose Tools Internet Options Security.

10.7.4.2 Java-specific settings in Internet Explorer

In order to fine-tune Java-specific browser settings, you have to choose the Custom Level security option. In this dialog box, Internet Explorer allows you to define two different settings: Scripting of Java Applets and Java Permissions. The first option, Scripting of Java Applets has the normal choices of Disable, Enable, and Prompt. Java Permissions (see Figure 10-8) has the following selections: Custom, Disable, High Safety, Low Safety and Medium Safety.

Figure 10-8. Setting Java permissions

Low Safety permissions allow an applet to access local resources, including disk operations and printing. Most users should not implement this level of permission unless their browsing access is limited to a fully trusted intranet. high safety permissions are equivalent to the Java sandbox (i.e. no local resources can be accessed). Medium permissions are the same as High permissions, but the applet is also requesting to use a scratch pad area of the local computer. The default setting in Internet Explorer 5.x of the Internet Zone is High Safety. The Restricted Sites setting has High Safety.

Internet Explorer 6.0's Restricted Sites disables Java.

10.7.4.3 Java Scratch Pad

Java developers needed a place to store persistent information that would be helpful to them and the end user. For example, a Java applet might want to store applet configuration information so that the next time it was started, it would retain the user's customized settings. Internet Explorer allows this under the medium and low permission settings. Although the scratch pad theoretically violates the Java sandbox, it is pretty secure. The scratch pad area is strictly defined, limited in disk space, and applets cannot modify files outside of the area. Internet Explorer will not allow users to define where on the disk it is located.

10.7.4.4 Customizing Java permissions in Internet Explorer

Internet Explorer Java developers assign (during the digital signing process) their applets a permission level ( High , Medium , and Low ) depending on what local resources may be required to run. The requested level of permission in the applet is compared to the user's Java settings for that particular Internet zone when the applet downloads. Depending on the comparison, the applet's access can be denied , downloaded and allowed the requested level of access, or downloaded and the user is prompted to allow or deny those additional resource requests . All unsigned code is assigned a high level of permission, by default.

Although most users are comfortable using Internet Explorer's predefined permission levels, the Custom Permission level allows a much greater level of control. You must select the Custom Java permission level to make the Java Custom Setting button appear. Clicking on the button will reveal the screen in Figure 10-9.

Figure 10-9. Java View Permissions

View Permissions displays all the Java permissions currently selected. There are three categories under the View Permissions tab: PermissionsEnabledforUnsigned Content, Permissions Enabled for Signed Content, and PermissionsDisabledforSignedContent. The descriptions should be self-explanatory.

There are 15 different permissions that can be assigned to each type of code, including the ability to print, local storage space, the ability to read and write local files, use of the clipboard, access local multimedia resources, and modifying the registry. You can explore the different default settings and see that signed code has more permissions than unsigned content. For example, signed content has limited file storage rights (Client Storage Limit value), whereas, unsigned content doesn't have a client storage permission assigned.

Select the Edit Permissions tab (see Figure 10-10) to change user-definable Java security settings. There are just two categories under this tab: Unsigned Content and Signed Content.

Figure 10-10. Edit Permissions

There are at least eight permissions you can Enable or Disable for unsigned content, while signed applets are allowed a third option, Prompt. If you Enable an applet's behavior, it occurs without prompting the user. If you Disable a behavior, the applet will be denied from running. If you choose Prompt, you'll be presented a dialog box showing all the permissions the applet is requesting and you'll be allowed to approve or deny the applet (as a whole). If an applet contains just one denied or prompted permission, the entire applet is acted upon as a whole.

You can determine whether applets can read, write, or delete files; whether an applet can contact another computer other than the one it came from; whether it can execute another program; whether an applet can print; whether an applet can use a scratch pad area; or whether the applet can prompt the user for file access options. With the last permission, the applet must display input asking the user to complete the file operation. For example, if an applet wants to open a file, it will prompt the user with a File Open dialog box, allowing the user to select and confirm which file to open. Because it involves user input, it is considered somewhat safer than unprompted file operations by some experts.

In general, signed applets should have permissions set to Enabled or Prompt. Unsigned applets should be run in the sandbox and denied all permissions that ask for more access. That said, many applet developer applets require Java permission modifications before they can run. The most common permission I see applet vendors requesting is the ability to connect to other remote network computers with the Access to all Network Addresses setting, which can be dangerous in the wrong hands.

Unfortunately, you cannot grant a particular permission toward one applet only in Internet Explorer. If you give one unsigned applet the ability to read and write files, all unsigned applets arriving from the same Internet security zone have the same permissions. Be careful when you lessen security settings.

10.7.5 Apply the Latest Security Patches

Rarely does a month go by without a new security patch becoming available for your operating system or browser. Typically, a security patch is released within a few weeks of a particular security hole being announced. You can go to Microsoft's Security web site at http://www.microsoft.com/security. Windows 98's Windows Update feature can be used to automate the process, but not always. It also can't hurt to monitor security groups like comp.java.security , NTBugTraq , CERT , or CIAC .

10.7.6 Use the Latest Browser Version

Nothing can beat using the latest version of your browser. Individual security patches are often gathered together and released as a minor version upgrade.

10.7.7 Know Your Java CLASSPATH

Your CLASSPATH memory variable lists the directory path for trusted Java class code. Be sure that you only place JVM files and other harmless code in any directory listed on your CLASSPATH. A few Java applets include documentation suggesting that you install their files in a CLASSPATH directory to gain additional benefits. If the applet doesn't need to run outside the sandbox, why risk it? Of course, browsers incorporating the enhanced Java 2 security model don't run quite the risk from this sort of attack, but it can't hurt to follow the same guidelines.

10.7.8 Disable Plug-ins

Plug-ins present an unverifiable security risk. In situations requiring high security, you may want to disable the ability to download and attach plug-ins. This can be accomplished in Internet Explorer with Tools InternetOptions Security Custom Level and check the appropriate option under RunActiveXcontrolsandplug-ins. The available selections include Disable, Enable, Prompt, and Administrator Approved. The last option only allows controls and plug-ins that were previously approved by a network administrator, with the Internet Explorer Administration Kit, to run.

10.7.9 Remove Unneeded Applets

List the Java objects installed in your browser and remove any that seem unnecessary. If you've got an object (or plug-in) that hasn't been accessed in a while, why keep it? This will free up scarce resources and lower the risk that malicious mobile code can exploit a vulnerability. To access the object list in Internet Explorer 5.x, choose Tools InternetOptions General Settings ViewObjects. Then you can then select the object and choose File RemoveProgramFile.

10.7.10 Avoid Malicious Sites

To avoid executing potentially malicious code, don't visit sites that might contain dangerous programs. Sometimes this is harder than it sounds. If you stick to strictly commercial business sites, you can minimize your risk (although any site carries some risk). Companies trying to make a buck have incentive not to nuke your system, but there have been a few cases of legitimate sites being hacked and malicious code placed there. You want to avoid visiting malicious hacker web sites for sure. You cannot trust those sites to play by the rules. Many hacker web sites intentionally try to infect visiting machines in an effort to spread their malicious code. I always disable my browser's active content features when entering potentially hostile territory. It only takes 10 seconds.

10.7.11 Be Aware of Social-Engineered Malicious Code

Always be suspicious of any window that suddenly pops up in the middle of your Internet surfing asking for your name and password or credit card number. Malicious code can wait till you enter a place where those types of prompts are common and then pop up their bogus windows requesting information. Look for window banners indicating that the requested window is coming from a malicious control or applet. Unless I initiated the dialog box requiring my password or credit card information, I never type it in.

If you follow these prevention recommendations the risk of a malicious Java exploit is significantly minimized.


Team-Fly

Top