Re: WSJ on Big Java Flaw
[snip]
Mr. Felten said that unscrupulous people who discovered the flaw could boobytrap a Web page on the Internet, essentially seizing control of the browser software of any PC that tapped into that page. At that point, the hackers could read or delete an entire hard disk of data files. "The consequences of this flaw are as bad as they can be," he said.[..]
The generalized halting problem comes to mind...
Since it can be proved that there's no complete set of heuristics to tell if a given program has a characteristic (such as "secureness") then sooner or later someone will discover another security flaw.
A question is whether a simple patch is made or if the set of heuristics is widened (ie, learn from mistakes) so that similar flaws can be found based on knowledge of that one flaw.
Since this Java error is probably deep in the bytecode interpreter, the question is will Sun patch this *particular* problem, still allowing others, or will it have to rewrite the interpreter so that it enforces the language more rigorously? They are under pressure to make a "quick fix" (they've promised something in two days), but real security needs to be built in to a system from the ground up, with disciplline and thorough design. If they need to redesign their approach to implementing the bytecode interpreter, that could take weeks, months? BTW, its a testament to security through code review, as the Princeton team probably could not have discovered this deep flaw without looking through the code. David Macfarlane.
We are doing several things: 1) continuing a "scrubbing" of the code, to look for holes so we can fix them 2) listening (really) to all comments about the applet security model and mechanisms - some people fault the model, others fault the mechanisms, and I'm interested in all critical feedback and find it helpful 3) continuing to be committed to source code releases to continue vetting by internet community 4) working with others in the networking security community to design ways to expand the functionality allowed to applets in a secure way 5) working on mechanisms to support signed classes, so that people will be able to authenticate downloaded code. Granted just because code is authenticated, that doesn't necessarily mean it's trusted As technical info on those things is written down, we'll put it on our web site for review and criticism - Marianne JavaSoft, Sun Microsystems mrm@eng.sun.com mrm@netcom.com
participants (2)
-
dmacfarlane@zip.sbi.com -
mrm@netcom.com