10.3 Java Exploits
10.3 Java Exploits Java has a wonderful security model that almost perfectly balances usability with security. To pull off this delicate balancing act took a lot of smart people, a lot of code, and a complex set of checks. And for the most part it works! Unfortunately, as any security expert will tell you, complexity -- and Java's security model is complex -- increases the chances that something will break. Java's sandbox has been violated several times and even applets, which do not violate any of the rules, can introduce annoying denial of service attacks. 10.3.1 Paid to HackThere are thousands of hackers interested in exploiting malicious mobile code. Entire groups, like Germany's Computer Chaos Club, use a professional, team approach to hacking Java. Everyone wants to be the first to " prove how unsecure Java is." Fortunately, there are a few dozen highly skilled professional groups working to find the latest exploit before malicious hackers can. Probably the most famous group analyzing Java is Princeton University's Safe Internet Programming Team (SIP) (http://www.cs.princeton.edu/sip). Using support garnered from both public and private entities, SIP is the premier research group studying mobile code systems. They have a serious bent toward Java, but are the group to talk to about any malicious code exploits. Included in the team are several other university groups, graduate students dedicated to debugging Java, and JavaSoft's own security team. 10.3.1.1 History of Java exploitsJava was released in 1995, and by the next year dozens of attacks and holes were found. To date, there have only been a handful or two of serious Java exploits that can compromise a system. Most of them were discovered by the good guys listed above. Typically, a Java security researcher finds a hole, tells the appropriate vendor, and a patch is released to close the crack. There are dozens to hundreds of less serious exploits, which only bother the end user and are fixed with a quick reboot. As of this writing, there has never been a serious Java exploit successfully used and documented in the wild. That could change, but that's the way it is now. 10.3.2 Types of ExploitsMost Java exploits can be classified as two types, each with four damage categories. The two types are either attempts to break the Java sandbox security model or attempts to execute malicious code within the boundaries of the sandbox . Depending on what they do next, the level of damage can be categorized as annoyance , denial of service , limited intrusion , or complete system compromise . A third type of malicious Java code, not talked about much, comes in the form of computer viruses and Trojans. 10.3.2.1 Attacks within the sandboxMost hostile Java applets have been annoying. They make continuous noise or sound, write silly graphics to the screen, or pop up lots of windows. They are annoying, but they don't compromise system integrity or steal information. Denial of service attacks are related and can be annoying, but they also take control of your system in such a way that your browser or the Java runtime environment becomes unusable. They attempt to use up system resources (memory, file pointers, windows, CPU cycles) as quickly as they can until the machine becomes very sluggish or even crashes. There have been applets designed to silently kill other applets. Denial of service attacks usually don't end until you close your browser or restart your system. These types of attacks don't break the Java sandbox, but they still cause problems, nonetheless.
Simple denial of service attacks are easy to make because Java does not limit how much CPU activity an applet can take. All a malicious program has to do is request a thousand windows or calculate pi to the billionth place and your whole Java system will come to a halt. Because Java must have the ability to manipulate its own runtime environment, it probably means that we will be forever plagued by annoying applets. Expect that Java's creators will eventually put a cap on how much of the total system resources an applet can use, but until then, your only real protection against malicious mobile code is to run only trusted programs from a trusted source. 10.3.2.2 Social engineering appletsHackers can use applets to "social engineer" their way past security blocks. In the past, a hacker might have called up a company's help desk pretending to be some clueless worker who has forgotten his password and wants a new one. The help desk personnel probably don't recognize every employee's voice and are often only too happy to help. Voil ! The hacker now has a valid password to attack with from the outside. There are several different web-based attacks where users are social engineered into releasing confidential information. Security experts have seen this attack demonstrated using HTML browser vulnerabilities, and using Java applets only adds to the realism . A malicious applet could claim to be some sort of game that the user plays over and over. But hidden from the user, the code waits for him to surf to a popular search site and puts up the fake message, "Congratulations! You're our billionth customer and we want to reward you with $1,000.00. Just type in your credit card information into our screen form so we can transfer the winnings to your account." The credit card information is then sent back to the hacker's web site. 10.3.2.3 Java viruses and TrojansAs a full-fledged programming language, it did not take long for hackers to use Java to write computer viruses and Trojans. However, neither type violates the confines of the security sandbox, and as such, aren't much of a threat -- yet. If downloaded over the Internet and executed within the confines of a browser, all their mischievousness will be stopped by the Security Manager. An error message is the most that would occur and the malicious code is not executed. However, if executed locally (i.e. after being saved to disk as a file), it can infect other local Java program files and applets. As such, Java viruses and Trojans aren't much of a threat to most of us. Only Java programmers need to worry. Fortunately, no Java viruses or Trojans have been found in the wild. 10.3.2.4 Applets that break the sandboxThese last two categories of applet damage, limited intrusion and complete system compromise , worry security experts the most. Malicious applets, which can gain unauthorized access to a user's system, break Java's sandbox. Annoying applets can be avoided, but these real threats can steal or damage data. A broken security model is no security. If a malicious applet can get out of the sandbox, there is no limit to what it can do. Files could be transferred, disks formatted, passwords stolen, screens recorded, and systems exploited. Java was built to explicitly prevent the last two types of attacks. In the world of Java security, few experts are concerned about attacks that don't compromise the sandbox security.  |
| | |
Team-Fly  |
| Top |
EAN: 2147483647
Pages: 176