[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Java insecurity - long - argumentative - you are warned.


>> > While all this checking appears excruciatingly detailed, by the time
>> > the byte code verifier has done its work, the Java interpreter can
>> > proceed knowing that the code will run securely. Knowing these
>> > properties makes the Java interpreter much faster, because it doesn't
>> > have to check anything.
>Yikes!!  I'll leave this for someone else to address.  This sounds to me
>like a variation on virus scanning.  I think that there are far more
>reputable virus experts than I who can comment and expand on *flaws* with
>that approach.

This "checking," as any comp-sci undergrad will tell you, amounts to solving
the halting problem for the java interpreter. While this is possible for a
finite state automata like the java interpreter (made more difficult by the
fact that it can use the "net" for additional state), it is not even
remotely feasable.

If you can write a checker that works in a reasonable amount of time, I'll
write a turing machine simulator that'll do something nasty if the input
machine halts. Then we'll split the fame and fortune for solving the 5 state
Busy Beaver problem. Deal?

Version: 2.6.2


Dietrich Kappe | Red Planet    http://www.redweb.com
Red Planet, LLC| "Chess Space" | "MS Access Products" |  PGP Public Key
1-800-RED 0 WEB|    /chess     |       /cobre         | /goedel/key.txt
Web Publishing | Key fingerprint: 8C2983E66AB723F9 A014A0417D268B84