 |
|
Securing Java, a successor volume by Gary McGraw and Edward W. Felten to their 1997 Java Security, is an ambiguous book. Securing Java is really about insecuring Java. It's about errors, errors of strategy and tactics, errors existential in nature, errors which potentially allow the malevolent cracker to code what is literally a killer Java applet.
McGraw and Felten are part of the security research community. They know whereof they speak and describe the taxonomy of nearly every recorded Java security lapse, whether inherent in Sun's design or resultant from vendor miscues in virtual machine implementation. While many of the holes in the model have already been patched, the emphasis is on what types of things to look for, from what directions one might anticipate finding a security hole. "Security holes can be likened to pitons," the book says, "Sometimes one piton is enough to help a climber make it to the top ... other times, more than one piton may be needed."
Securing Java is excellently edited and designed, a gripping technical "whatdoneit" that should have Dilbert sitting on the edge of his seat. The entire book can also be read on the web at http://www.securingjava.com/, complete with search engine. The publisher is daringly operating under the theory that you will like what you see and need a copy to carry with you on the airplane. The authors do not believe that the free web version will impact sales of the printed book. In any event, you can order the paper book from the web page.
Overall description is engagingly rich but the discussion of internals is evasive. Securing Java reads like a roman-a-clef thriller where, if the author told you more, "he'd have to kill you."
Having in mind the stunning revelations about intellectual freedom in America that emerged from the experiences undergone by programming gurus like Phil Zimmerman and John Gilmore, I asked Gary McGraw about the team's tantalizingly vague literary treatment of a computer science topic.
"We've been criticized by one guy (Rusty Harold) who said we're proponents of security by obscurity," McGraw told me. "We say: We know what happens in practice is that people will write an exploit script, and the ankle biters will use it like mad."We published full details of security holes in 1996, yet there has never been an attack applet in the wild. We didn't provide exploit scripts, just described it so you can understand it, so that people in the know with hands-on experience mucking around this stuff can learn how to write protectively, yet so the lazy can't make an exploit script."
Is Java securable?
"The security situation is very tricky," says McGraw. "The goal is to inject [a] lot of reality into the discussion. The market is ripe for snake oil. People treat security as an add-on feature. Security doesn't work this way; it's like reliability, dependability, the other-ilities."Ships used to sink in [the] 1800s, then they built the unsinkable ship which sank, which was big news more than a lot of other ships that sank. That's 'the Titanic effect.' A language comes out, they say, 'Java is secure.' The research community took that as a challenge.
"But Java is by far and away the most reasonable approach to attempting to secure mobile code. I was under the false hope in 1995 that Java would be better than it is."
Much of Securing Java is educational; there are also practical suggestions. Chapter 7, "Java Security Guidelines," presents 12 rules for Java developers and a lengthy series of guidelines for Java users. The appendices cover, among other things, URLs to sites relevant to Java security and a long list of frequently asked questions about Java security (the Java Security FAQ).
Coauthor Ed Felten is known to the general public as the expert witness for the U.S. Department of Justice who, in the Microsoft antitrust trial, noticed the discrepancy in the video because he wrote the program to remove IE from Win95. This became known as "to Feltenize" a Win95 machine. McGraw recounts that over beer one evening several team members took turns offering alternative definitions of "to Feltenize," definitions which, unfortunately, McGraw could not precisely recall during our conversation.
Are the authors leveling with us? Perhaps one needs experience studying the chess literature to assess Securing Java. Books on the chess openings strive earnestly to convey the overarching positional considerations inherent across vast numbers of possible games, all arising from the same few opening moves. At the same time, authors of chess books avoid giving away the specific moves they plan for the next championship cycle.
McGraw and Felten admit they are holding back. But what they have to say is, if one is concerned with securing Java, worthy of hearing, especially since they write so well.
-- Jack Woehr
| Readability |
|
| Originality |
|
| Organization |
|
| Accuracy | Not Rated |
| Consistency | Not Rated |
| Depth | Not Rated |
| Timeliness |
|
| Editing |
|
| Design |
|
| Overall Value |
|
Explanation of ERCB rating scale: No stars = unacceptable, 1 Star = marginal, 2 Stars = average, 3 Stars = above average, 4 Stars = exceptional.