Confirmed on Netscape 4.5 running on an NT 4 SP 4 box. Loaded up a similar applet on the internal network without standard applet callback methods of stop() or destroy(). Kill the window that opened the applet and the socket remains running (as expected, and only if some other application in the same process space is running). Fun! --Shido Shidoshiat_private -----Original Message----- From: Bugtraq List [mailto:BUGTRAQat_private] On Behalf Of Giao Nguyen Sent: Wednesday, February 03, 1999 3:49 AM To: BUGTRAQat_private Subject: Re: Unsecured server in applets under Netscape BVE writes: > > The error in your analysis is most likely that you were running Java code from > a class file installed on your local machine, as opposed to one which is > downloaded from a web site somewhere. The former is considered "trusted," > while the latter is "untrusted." You'd think so. Don't worry. I sat on this bug for two days to verify that I had everything workin right and that I didn't have any funny servers on my favorite port numbers. I tend to use 6969 whenever I want to test something. The first iteration of this worked. I was shocked. A coworker mentioned the exact same thing you did. So I put it on our development server. Loaded the web page. Same result. I then telnet to a machine approximately 3000 miles away on a separate network unrelated to the network I was on. Same result. Just for kicks I got some folks from other companies to help me verify that lunch didn't include liquids which the company might frown upon. Same result. The fact that my test was done on a Windows box and others repeated the tests on a Unix platform confirmed that this was not a Windows + Netscape related problem but that it was indeed a Netscape specific thing. > Any class file you've compiled on your local machine will be considered > "trusted," and will be allowed to do pretty much anything it wants. Similarly, > any class file you've copied to your hard drive, as opposed to downloading from > within a web browser, will be considered "trusted." Yes, CLASSPATH contamination. I am aware of this. To verify that it's not CLASSPATH contamination, I'm putting the sample up at http://www.cafebabe.org/sapplet.html It doesn't do anything other than allow connections to be made. It listens on 6969 btw. Now, the security measures as implemented by Netscape doesn't allow for the equivalence of an accept() call to be made. However, it could present an opportunity for DoS attacks. The source is at http://www.cafebabe.org/Sapplet.java . In retrospect, I think the topic is wrong. It should have been different. The opportunity is still present for those who has a use for such thing. YMMV. <deletia> Giao Nguyen
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:32:30 PDT