Article 817 of comp.lang.java.security:
Centuries ago, Nostradamus predicted that David Hopwood would write :

>Reposting article removed by rogue canceller.

Is that what happened to my original post ? I never saw it show up at my
"other" site :-(  .

>
>In article <51s6v4$p0s@nyx10.cs.du.edu>,

...

>
>We try to make sure that applets loaded from file: URLs have no more
>priviledges than other applets, because it is relatively easy to load an
>applet from any site onto the local disk.
>

Given that this is true, I may see a bit of a problem here.  Applets can only
open network connections back to the server they originated from.  If an
applet is loaded from the filesystem, then that applet's "server" is the 
local machine and the applet can connect to ports on it.

If a network loaded applet could cause another applet to be loaded into the 
cache along with its html file, the network loaded applet could call
showDocument with the "file:/" URL of the cached html file that points
to the "hostile" applet waiting in the cache directory. The newly running 
hostile applet has no extra privileges, but it would be free to connect 
to local ports and perhaps access private news groups or other info.  The 
new applet could then send information back out using port 25 ( Email ).  
This would also allow the new applet to generate "hostile" email with no 
header trace back to the original site.

This attack would depend on being able to calculate the name of the cache 
file and having the  "hostile" applet named after it.  Easy in Internet
Explorer, doable ( as you state below ) in Netscape.

Farfetched ? Perhaps.  Much pain for little gain ? Likely.  A possibility ?
I'm not sure yet.


>The security FAQ at java.sun.com says that Netscape treats 'local'
>applets differently (http://java.sun.com/sfaq/#summary); as far as I know,
>that is incorrect (even in 2.x). If that was the case, it would be
>a bug.

As pointed out to me by others, the section by itself is misleading and
a bit out of context.  Earlier in the document, Sun states that applets
loaded from the file system outside of the CLASSPATH are treated 
just like network loaded applets. The "#summary" section only refers to 
applets loaded from the filesystem within the CLASSPATH.  I guess I should
have read the entire document more carefully :-(  .


>
>Note that it is possible for the user to manually add new classes to the
>CLASSPATH, but this should only be done for classes that are completely
>trusted.
>
>> Thus just by visiting a site, the class and html files are down-loaded into
>> the cache, and the applet basically re-executes itself from the disk and
>> gains more privileges. I don't know if the name of the Netscape cache
>> files can be calculated, but I understand that Internet Explorer uses
>> original names in its cache, making the attack easier.
>
>Yes, Netscape cache filenames can be calculated, and Explorer does use the
>original names. It isn't a problem if local applets have no extra priviledges,
>though.

No privilege problem, but perhaps a problem because the applet could be
running with a different server context.


>
>David Hopwood
>david.hopwood@lmh.ox.ac.uk
>dhopwood@netscape.com
>
>Any opinions expressed above are not necessarily those of Netscape.
>


-- 
--------------------------------------------------------------------------------
Jim Buzbee                                |  "I was gratified to be able to 
jbuzbee@nyx.net                           |  answer promptly, and I did. I
http://www.nyx.net/~jbuzbee/bat_house.html|  said I didn't know."   Mark Twain