Most read:
- The case for Java modularity
- Four harmful Java idioms, and how to fix them
- iBATIS, Hibernate, and JPA - Which is right for you?
- Build the enterprise with EJB 3, JBoss Seam, and Maven 2
- Hello, OSGi, Part 1: Bundles for beginners
Popular archives:
Java Q&A Forums - Let the great migration begin
We're pleased to announce the first phase of the integration of the Java Q&A Forums with our community platform, JavaWorld's
Daily Brew. Whether you're one of our longtime forum users or a brand newbie, we hope you'll visit the Java Q&A Forums in their new home alongside JW Blogs.
Featured Whitepapers
| Enterprise AJAX - Transcend the Hype |
| Oracle Compatibility Developer's Guide |
Letters to the Editor
Quite a few readers responded to last month's JDK 1.2 bug report with skepticism at best; author Kieron Murphy takes on the critics. Plus: VolanoMark's John Neffenger addresses a mailbag full of JVM scalability queries; Merlin Hughes tackles the mathematical intricacies of 3D programming in Java; Allen Holub defends his approach to coding; and technical Q&A with Chuck McManis, Todd Sundsted, Bill Venners, and John Zukowski
NEW_SUBJECT: "First bug bites Java 1.2 -- Mozilla stung" by Kieron Murphy
READ_ME: /jw-08-1998/jw-08-12bug.html
LETTER_HEAD: What bug?
Kieron,
I am curious about what bug Felten and co. have found that needs to fixed in "all JVMs." I have looked in great depth at the JVM definition, and do not believe any class loading or type verification bug exists in the JVM.
Vijay Saraswat
LETTER_DIV: LETTER_HEAD: "Early access" software clarification
Kieron,
I think "early access" to software is intended to flush out bugs. Early access software should not be used in a production environment; it should be used only by developers.
Mike LaRocca
LETTER_DIV: LETTER_HEAD: Sensationalism?
Kieron,
The sensational title of your article does not match its reality. How can you state in the title that the first JDK 1.2 security bug has been discovered when, at the end of the article, you state that it's not exploitable in the JDK?
Li Gong
LETTER_DIV: LETTER_HEAD: Either/or
Kieron,
Which is it? Your article states in the second-to-last paragraph: "I've just taken a look at Communicator 4.50 PR1, and the holes still exist there." However, the link you provide for Princeton University Secure Internet Programming (SIP) report of July 1998, clearly states:
This flaw is fixed in Navigator 4.5. We have verified that our demonstration applet does not work on Navigator 4.5.
Please clarify.
Name withheld
Kieron Murphy responds
AUTHOR_REPLY:
Readers,
To begin, any defects in the composition of the article are mine alone. I stand by the article, but admit it could have been better.
To clarify matters, I offer the following comments on some of the criticism the article has received.
The main complaint seems to be that the conclusion does not satisfy the premise. One reader notes: "The sensational title of your article does not match its reality."
I made several attempts to contact appropriate representatives at Netscape and Sun for comment on this point, but neither organization responded in any detail for the record.
Informed sources told me, however, that the dynamic linking problem in JDK 1.x and all contemporary implementations of the Java VM is a serious flaw. A distinction must, of course, be made between the existence of a flaw and its actual exploitation. The importance of the Princeton hole, in my opinion, was due to its breaking the barrier of successful type confusion in current and planned designs -- especially, by mounting a three-phase attack.
That type safety was only broken in Navigator 4.x should not be considered a disturbance; it should be an alarm. Princeton's SIP researchers have long been at work on a theory that the dynamic linking mechanism in Java may have unsound technical properties. The Hostile Applets home page's class loader bug, discovered earlier this year, and the security manager trick in Navigator simply provided the topography for an attack.
In my view, they succeeded in accomplishing their mission.
Java developers should be very defensive in creating code. Designing security policy for users is of paramount concern for the success of the language and platform.
