eggs_to_applets.html

[Cryptic Dancer]

                                  [INLINE]
                                      
                    Java Security: From Eggs to Applets
                                      
                      Copyright (c) 1997 Mark D. LaDue
                                      
   Heave an egg through an open window almost anywhere in the world
   today, and the odds of striking a Netscape user are in your favor. The
   odds are even better that this person either knows nothing of Java
   programming or adheres to the many myths surrounding Java security.
   Pick up almost any book on Java programming, and you will find the
   same superficial and misleading treatment of security issues. Gary
   McGraw and Edward Felten's recent work, "Java Security: Hostile
   Applets, Holes, and Antidotes," is the first book to address the
   myriad problems raised by Java. It clearly and concisely explains past
   problems, current issues, and future risks. McGraw and Felten grab the
   high and mighty Java industry by the ear, and they offer sane and
   sensible advice to every level of Java programmer and user.
   
   One of the strongest points of the book is that it offers as much to
   the Java neophyte as it does to the seasoned programmer. The first
   chapter provides a brief survey of Java's concepts, while the second
   chapter gives a detailed introduction to the current Java security
   model. From the beginning the reader is led to pose tough questions
   and weigh the risks versus the benefits of using Java. The book's
   classification of threats from applets is apt, as is its
   classification of hostile applets into two camps - the more serious
   "attack" applets, such as those created by Felten's team at Princeton,
   and the less threatening "malicious" ones, such as those on display on
   the Hostile Applets Home Page. Two chapters provide the essence of
   both types of applets, and the penultimate chapter proposes six common
   sense guidelines for using Java more safely. It would be a grave
   mistake for anyone to ignore the book's questions or to accept the
   answers on faith from some corporate behemoth.
   
   Unlike many books aimed primarily at the novice, "Java Security" has
   much to offer the experienced Java programmer. Foremost of all, its
   critical attitude toward Java security is a breath of fresh air for
   the legions of self-styled "Java Consultants," who all too often have
   inhaled the wind of a flatulent Duke for far too long. Those already
   acquainted with Java will find the detailed discussions of "attack"
   applets in Chapter 3 and "malicious" applets in Chapter 4 very
   profitable. The book's final chapter on "Tomorrow's Java Security" is
   a nice preview of new security features likely to appear in future
   releases of Sun's Java Developers Kit. While these portions of the
   book are more suitable for the seasoned Java user, the novice willing
   to look elsewhere for some additional details will certainly profit.
   
   Without a doubt the most exciting and enlightening chapter of the book
   is the fifth one, "Antidotes and Guidelines for Java Users." It
   succeeds admirably in its twin goals of discussing high-level concerns
   about Java and providing a concise set of security guidelines for
   users to follow. Remarkably, although it is the shortest chapter in
   the book, in the course of its first dozen pages it offers as many
   sound reasons why Java will continue to pose security risks.
   
   One of the most interesting observations to emerge in this chapter is
   that Java byte code is more powerful than Java source code. While
   every program written in Java can be compiled to byte code by a Java
   compiler, it is possible to create class files which no Java compiler
   can produce, and yet, which pass the Verifier with flying colors. Not
   only is it possible to create such non-compiler class files, it is a
   simple matter to do so, and the number of such non-compiler class
   files far and away exceeds the number of class files producible by
   Java compilers. Thus no matter what claims are made, and even
   demonstrated, for the security of the Java language, all bets are off
   when it comes to byte code running in the Java Virtual Machine. This
   is one of the most important facts brought to light in the book, and
   it is a topic crying out for more active research.
   
   Another interesting item mentioned in Chapter 5 is that the ease with
   which Java class files may be decompiled to source code also entails
   certain risks. Using the celebrated Mocha decompiler, for example, it
   is easy for a hacker to decompile class files to source code and scour
   them for weaknesses, and it is just as easy for a Java developer to
   decompile a business competitor's work and search for trade secrets.
   It is worth observing that these two topics in Chapter 5 are not
   unrelated. There is now available a Java application,
   [1]HoseMocha.java, that strategically adds byte code to Java class
   files. Class files protected by HoseMocha continue to pass the
   Verifier and run just as before, but they defeat the Mocha decompiler
   because there is no source code that can produce them. The Mocha
   decompiler could be taught to defend itself, of course, but it is
   unlikely to be able to do so effectively against the wealth of byte
   code tricks that can be used to attack it. The power of Java byte code
   is simply too much greater than the power of Java source code. This
   fact is likely to pose a continuing threat to the security of the Java
   language for years to come, and it may well prove fatal.
   
   In fairness, it should be noted that the list of references in "Java
   Security" has several errors and significant omissions. It seems
   likely that the errors are due to editorial carelessness, and they
   cannot be said to detract much from the book's success. Missing from
   the references are the authoritative works in "The Java Series,"
   written by members of the JavaSoft team and published by
   Addison-Wesley. Particularly worthy of inclusion are "The Java
   Language Specification" by Gosling, Joy, and Steele as well as "The
   Java Virtual Machine Specification" by Lindholm and Yellin. The
   authors definitely should consider including these in the references.
   Perhaps these minor foibles will be corrected in a later printing or a
   second edition.
   
   The only other shortcoming that could be corrected is the book's
   length. It is altogether too short, and a work of twice the present
   length on the same subject would still leave much remaining to be
   said. But perhaps this is a strength of the book and not a weakness.
   One can only wish that McGraw and Felten's "Java Security" had
   appeared a year earlier and had already been read by Java's
   cheerleaders and hucksters. Perhaps then more of the problems
   discussed in this book would have been solved by now, and fewer risks
   would remain. Until those problems are addressed, and even after they
   are, "Java Security" will be a fine antidote for all of the Java
   fanfare.
   
                                  [INLINE]

References

   1. http://www.math.gatech.edu/~mladue/HoseMocha.java