Article 841 of comp.lang.java.security:
Centuries ago, Nostradamus predicted that <DyA6y2.5rJ@student.twi.tudelft.nl>
would write  :

>Jim Buzbee (jbuzbee@nyx.net) wrote:
>: Centuries ago, Nostradamus predicted that David Hopwood would write :
>
...

>: >
>: >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 
>
>Without success. This should throw a security exception! Applets may not open 
>URLs with another protocol than they are loaded with themself. At least 
>NS Navigator 3.0 enforces this rule, I haven't checked others. 
>

I think you are mistaken here. Applets may not _connect_ to ports on systems
other than their original server, but they are free to cause the browser
to open _any_ valid URL ( mailto:, news:, http://, etc. ) with the
showDocument call.  The network loaded applet cannot directly communicate 
with any applet that may have been loaded by the showDocument call, but
the file loaded applet will start up and run with a server context of the
client machine, not the original network server.

I have tested this and it works as I stated above.  A network loaded applet 
successfully called showDocument with a file:/ URL that pointed to a html
file and applet on the _local_ disk.  My local file loaded applet then was
able to open a connection ( port 25, Email ) on the client machine and
send out Email without the original server machine being involved.
But of course the real issue is still getting the files on the file system in
the first place.

>: 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.
>
....

>: No privilege problem, but perhaps a problem because the applet could be
>: running with a different server context.
>
>Umm, IMHO it is a privilige problem. The applet from the web server and one
>from the local file system are in a different security domain. They should
>not able to do things in each others domain. Note that this policy currently
>isn't implemented in Java! The applets are allowed to kill, suspend, etc.
>each others threads without restrictions, for example. IMHO this is wrong:
>the applets resources should be invisible to eachother.
>

Agreed on the thread issue, but I have shown that that applets can at least
get into the local file system security domain.

>Bastiaan
>
>Bastiaan.Bakker@TWI.TUDelft.NL
>
>

Jim


-- 
--------------------------------------------------------------------------------
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