By Godfrey Nolan
Suppliers fret over vulnerability of Java; ActiveX provides little solace.
When Sun Microsystems launched its Java portable applications development language in 1995, James Gosling, the technical guru who oversaw the project, told Computer Business Review that 90% of the technology [in Java] is dealing with security. But, he added, security is never absolute: People can dump boulders from aeroplanes.
Over the past 18 months, Java has taken the computing world by storm. And although there have been some concerns about Java’s memory leakage – its tendency to use up systems resources without regard to the system’s other requirements – there have been no boulders from aeroplanes. Encouraged by Java’s power, portability and its ability to turn static Web sites into something resembling interactive CDs, suppliers have embraced the language. Corel and Lotus, for example, are both releasing Java versions of their office suites. But one problem – at this stage mostly a theoretical one – is starting to concern the commercial developer community. Is a Java applet safe from intellectual property theft once it is downloaded from a Web page? The answer that is emerging from the Java Internet newsgroups after at least a year’s worth of discussion is a resounding no. In fact, Java applications are particularly prone to being re-engineered and copied – to the extent that there are now fears it may harm the language’s take-up. The problem is a technical one. Running a Java program or applet is a two-stage process. The source code is compiled into a portable byte code, known as an applet. When a Web browser downloads an applet, the browser’s local component, the Java virtual machine or JVM, interprets the byte code and converts it into executable machine code. JVMs have been written for all the major operating systems, which accounts for an applet’s portability. But to achieve this portability – and pass Sun’s security procedures – an applet needs to contain a large amount of symbolic data. As with other computer languages, such as C and Visual Basic, a number of decompilers are available for Java that can speedily reverse-engineer a program, granting partial and often complete access to the original source code. This means that by using decompilers, it becomes possible to copy, reproduce or re-engineer software programs. Because Java applets are small, however, the original source code is often easy to understand, making them particularly vulnerable. Although there is no evidence yet that Java development is been held back for fear of decompilation, this may change as suppliers realise that their code can be compromised. The problem is a real one. While recovering from surgery in the Netherlands, Dutch programmer Hanpeter van Vliet wrote Mocha, the most famous decompiler to date. Mocha is easy to install and surprisingly effective. Out of ten applets downloaded from the Web, Mocha decompiled six completely and a significant amount of code was decompiled from the remaining four. This reverse-engineered code can then be modified, removing any security or licensing restrictions, before being recompiled for use on another Web server. Van Vliet stresses that Mocha should only be used for learning purposes, but, the potential for piracy is clearly high. Commercial decompilers are also available. Rational Rose/Java, currently in beta, is a Java compiler that will also import and decompile applets, as will the soon to be released IceBreaker from Breaker Technologies. Written in Java, IceBreaker consists of three windows, one containing the partially decompiled source code and the other two containing the real byte code and the partially completed byte code. Any differences between the two byte codes are shown in red. The hacker guesses the source code, recompiles, and gradually reduces the number of red lines. IceBreaker relies on the fact that the JVM’s stack is a simple system with a limited number of possible byte codes. With a little practice IceBreaker will decompile almost any small applet. Javasoft, Sun’s Java business unit, admits that Java decompilers are a problem and says that it is working on a solution. For example, it says that the next version of Java, Java Beans, and advances in component packaging, will solve the problem to some extent. But for the moment, the Java security model focuses on making the browser safe and tends to ignore the developer. What can commercial software developers do to safeguard code? Van Vliet also sells Crema, a byte code scrambler or obfuscator that changes variable names to gibberish to stop any hacker understanding the decompiled code. However, obfuscated or not, the resultant decompiled code is still source code and can always be manipulated back into a readable form. Bob Foster of Symantec Internet Tools has a more radical suggestion. If you have code you want to hide, run it on your server. Don’t publish it (byte codes, object code, obfuscated, whatever) or others will be able to read it. But splitting code between the server and client can be inefficient, increasing Web server load, and may also attract unwanted visitors. And of course, it goes against the distributed computing ethic that underpins the whole Java ideal. The only effective way to prevent decompiling at present, say experts, is to encrypt applets. Breaker Technologies is currently trying to promote SoftSeal, a product which licenses Web content and prevents unauthorized access. Applets and images are encrypted and can only be displayed when authorised by a SoftSeal-enabled Web browser. Unfortunately, neither Microsoft nor Netscape’s browsers use SoftSeal or any other compatible software. Does all this give a crucial competitive advantage to Microsoft, which promotes the rival’ ActiveX technology? It seems not: Microsoft’s official position is that ActiveX and Java are compatible not competitive technologies. Sun/ Javasoft meanwhile, believes its primary security focus is to keep rogue applets away from a browser’s operating system. In any case, ActiveX has problems of its own. A group of German hackers recently broke into a user’s Quicken financial program using ActiveX, highlighting a security flaw. And analysts are also now suggesting that ActiveX is particularly virus prone. According to the Meta Group, Users must establish a policy for loading ActiveX and Java components from the Web or face significant hacker vulnerability.
