netscape4.5-applets.txt

1999-08-17T00:00:00
ID PACKETSTORM:12250
Type packetstorm
Reporter Packet Storm
Modified 1999-08-17T00:00:00

Description

                                        
                                            `Date: Tue, 2 Feb 1999 13:42:32 -0800  
From: Giao Nguyen <grail@CAFEBABE.ORG>  
To: BUGTRAQ@netspace.org  
Subject: Unsecured server in applets under Netscape  
  
Just for kicks, I wrote a sample applet that listened on a socket. I  
discovered that when the applet was loaded under Netscape (as tested  
with version 4.5), any hosts could then connect to the machine running  
this applet. I won't bore anyone with the code because it's so trivial  
that a novice to Java should be able to write it with ease after  
reading some documentation.  
  
According to Java in a Nutshell, 2nd edition, p. 139:  
  
* Untrusted code cannot perform networking operations, exception  
certain restricted ways. Untrusted code cannot:  
[...]  
- Accept network connections on ports less than or equal to 1024 or  
from any host other than the one from which the code itself was  
loaded.  
  
While the port number restriction is held by the VM, the point of  
origin restriction is not held at all.  
  
I don't feel qualified to comment on the full implication of this but  
I'm sure more inventive minds can arrive at more interesting uses of  
this feature.  
  
The work around is rather simple. Disable Java runtime in the Netscape  
browser.  
  
As hinted above, Internet Explorer's Java runtime does not exhibit  
this behaviour.  
  
I have contacted Netscape (via some truly useful web pages) but I've  
not received any responses to the following information. I hope it's  
useful to someone out there.  
  
Giao Nguyen  
  
------------------------------------------------------------------------  
  
Date: Wed, 3 Feb 1999 07:45:13 -0000  
From: BVE <bve@QUADRIX.COM>  
To: BUGTRAQ@netspace.org  
Subject: Re: Unsecured server in applets under Netscape  
  
Date: Tue, 2 Feb 1999 13:42:32 -0800  
From: Giao Nguyen <grail@CAFEBABE.ORG>  
  
Just for kicks, I wrote a sample applet that listened on a socket. I  
discovered that when the applet was loaded under Netscape (as tested  
with version 4.5), any hosts could then connect to the machine running  
this applet. I won't bore anyone with the code because it's so trivial  
that a novice to Java should be able to write it with ease after  
reading some documentation.  
  
According to Java in a Nutshell, 2nd edition, p. 139:  
  
* Untrusted code cannot perform networking operations, exception  
certain restricted ways. Untrusted code cannot:  
[...]  
- Accept network connections on ports less than or equal to 1024 or  
from any host other than the one from which the code itself was  
loaded.  
  
While the port number restriction is held by the VM, the point of  
origin restriction is not held at all.  
  
  
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."  
  
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."  
  
--  
  
-- Bill Van Emburg  
Quadrix Solutions, Inc.  
Phone: 732-235-2335, x206 (bve@quadrix.com)  
Fax: 732-235-2336 (http://quadrix.com)  
"You do what you want, and if you didn't, you don't"  
  
------------------------------------------------------------------------  
  
Date: Wed, 3 Feb 1999 00:49:10 -0800  
From: Giao Nguyen <grail@CAFEBABE.ORG>  
To: BUGTRAQ@netspace.org  
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.  
  
Giao Nguyen  
  
------------------------------------------------------------------  
[http://www.cafebabe.org/sapplet.html]  
  
This page contains an applet listening on port 6969. It doesn't do  
anything other than that. How useful is it?  
  
<applet code=Sapplet.class width=10 height=10>  
</applet>  
------------------------------------------------------------------  
  
  
------------------------------------------------------------------  
[http://www.cafebabe.org/Sapplet.java]  
  
import java.net.*;  
import java.io.*;  
import java.applet.*;  
  
public class Sapplet extends Applet {  
ServerSocket s;  
public void init() {  
try {  
s = new ServerSocket(6969);  
} catch (IOException io) {  
System.out.println("Well drat, it didn't work.");  
}  
}  
}  
------------------------------------------------------------------  
  
------------------------------------------------------------------------  
  
Date: Wed, 3 Feb 1999 14:51:36 -0500  
From: Tramale K. Turner <shidoshi@black.kage.net>  
To: BUGTRAQ@netspace.org  
Subject: Re: Unsecured server in applets under Netscape  
  
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  
  
Shidoshi@monkey.org  
  
------------------------------------------------------------------------  
  
Date: Thu, 4 Feb 1999 23:16:04 +0200  
From: Aviram Jenik <aviram@SECURITEAM.COM>  
To: BUGTRAQ@netspace.org  
Subject: Re: open socket in java  
  
nino wrote:  
  
> The implications are obvious. If any host can connect to the machine  
> running the aplet, you could tell java to do things like the boserver.  
> If  
> you have a completely open socket, its rock n' roll !  
>  
  
No, it's not.  
  
Yes, you can connect to the open socket, but the applet can't do any I/O, so  
it's basically harmless (just like any other applet).  
  
The fact that the applet accepts outside connections is nothing by its own  
(besides a bad feeling it makes anybody that knows something about  
security...). The only possible security implication is performing some DoS  
on that socket or combining this with another exploits  
You definitely can't write a boserver in Java.  
  
--  
-------------------------  
Aviram Jenik  
  
"Addicted to Chaos"  
  
-------------------------  
Today's quote:  
Religion ... is the opium of the masses.  
- Karl Marx, "Critique of the Hegelian Philosophy  
of Right", 1844  
  
------------------------------------------------------------------------  
  
Date: Fri, 5 Feb 1999 11:04:24 +1000  
From: Toby Chamberlain <toby@PEOPLESEARCH.COM.AU>  
To: BUGTRAQ@netspace.org  
Subject: Re: open socket in java  
  
nino worte:  
<snip>  
>  
> The implications are obvious. If any host can connect to the machine  
> running the aplet, you could tell java to do things like the boserver.  
> If  
> you have a completely open socket, its rock n' roll !  
>  
<snip>  
  
I may be missing something here, but from what I understand of the bug  
it _doesn't_ constitute a major security issue. All it means is that we  
have an open socket to a Java APPLET - (note: *not* a Java application)  
- running on the machine, and are still subject to the "sandbox"  
restrictions that applets have. We can't read/write files on the local  
machine or do anything that we couldn't do with an applet anyway.  
  
Please correct me if I'm wrong, but I don't think it's anything to get  
too excited about kiddies - the Java/Javascript combo that let's you  
read files (posted on bugtraq a month or so ago) is much more  
interesting :)  
  
Stay cool,  
Toby  
  
------------------------------------------------------------------------  
  
Date: Fri, 5 Feb 1999 08:18:39 -0500  
From: Hale <admin@DEVIANCE.ORG>  
To: BUGTRAQ@netspace.org  
Subject: Re: open socket in java  
  
Wether or not that could cause any problems is realted to the level of  
security that is imposed on java applets. Say you open a listening port  
on 139 or 23. If that sockets lays over the existing one, it could  
possible take traffic from it, and relay it to a remote host. You can do  
this with netcat, so I would think java applets would be subject to the  
same security..  
  
Pavel  
  
------------------------------------------------------------------------  
  
Date: Fri, 5 Feb 1999 09:09:25 -0500  
From: Lincoln Stein <lstein@cshl.org>  
To: BUGTRAQ@netspace.org  
Subject: Re: open socket in java  
  
Aviram Jenik writes:  
> nino wrote:  
>  
> > The implications are obvious. If any host can connect to the machine  
> > running the aplet, you could tell java to do things like the boserver.  
> > If  
> > you have a completely open socket, its rock n' roll !  
> >  
>  
> No, it's not.  
>  
> Yes, you can connect to the open socket, but the applet can't do any I/O, so  
> it's basically harmless (just like any other applet).  
  
The main issue, I think, is information leakage between the Web site  
that uses the applet and the applet's author. Consider this scenario:  
a Bad Guy puts out a compiled applet in the public domain that seems  
to do something innocent like chart business graphics. Some company  
then picks up this applet and uses it to display its confidential  
business plan to authorized hosts in branch offices. Unbenknownst to  
the company or the branch office, the applet has actually opened a  
listen socket, has accepted a connection from the applet's original  
author, and is currently transmitting the confidential information to  
an untrusted host!  
  
Lincoln  
  
--  
========================================================================  
Lincoln D. Stein Cold Spring Harbor Laboratory  
lstein@cshl.org Cold Spring Harbor, NY  
========================================================================  
  
------------------------------------------------------------------------  
  
Date: Fri, 5 Feb 1999 12:06:52 +0000  
From: Simon Kilvington <s.kilvington@ERIS.DERA.GOV.UK>  
To: BUGTRAQ@netspace.org  
Subject: Re: open socket in java  
  
nino wrote:  
>  
> BTW - dont be afraid to release the code. It makes it more easy to the  
> rest of us, to see what happened. And the script kids got lots of evil  
> tools out there, so I think they wouldnt be too interested in code they  
> have to alter before its useful.  
>  
  
here's the code - use Netscape's Java console to capture the  
class file, and then use something like Jad to decompile it...  
  
// Decompiled by Jad v1.5.5.3. Copyright 1997-98 Pavel Kouznetsov.  
// Jad home page: http://web.unicom.com.cy/~kpd/jad.html  
// Decompiler options: packimports(3)  
// Source File Name: Sapplet.java  
  
import java.applet.Applet;  
import java.io.IOException;  
import java.io.PrintStream;  
import java.net.ServerSocket;  
  
public class Sapplet extends Applet  
{  
  
public void init()  
{  
try  
{  
s = new ServerSocket(6969);  
return;  
}  
catch(IOException ex)  
{  
System.out.println("Well drat, it didn't work.");  
}  
}  
  
public Sapplet()  
{  
}  
  
ServerSocket s;  
}  
  
  
--  
Simon Kilvington, s.kilvington@eris.dera.gov.uk  
  
------------------------------------------------------------------------  
  
Date: Tue, 9 Feb 1999 09:54:42 -0500  
From: Tim Wright <wright@QUCIS.QUEENSU.CA>  
To: BUGTRAQ@netspace.org  
Subject: Re: open socket in java  
  
On Fri, 5 Feb 1999, Lincoln Stein wrote:  
  
> The main issue, I think, is information leakage between the Web site  
> that uses the applet and the applet's author. Consider this scenario:  
> a Bad Guy puts out a compiled applet in the public domain that seems  
> to do something innocent like chart business graphics. Some company  
> then picks up this applet and uses it to display its confidential  
> business plan to authorized hosts in branch offices. Unbenknownst to  
> the company or the branch office, the applet has actually opened a  
> listen socket, has accepted a connection from the applet's original  
> author, and is currently transmitting the confidential information to  
> an untrusted host!  
  
the missing information here that this scenario doesn't contain, is that  
the applet's original author must know the host that the applet is running  
on, in order to connect to the applet.  
  
This information can be easily sent by the applet to the bad guy by making  
a http request - hiding information in the URL. We implemented this type  
of communication, allowing a java applet to communicate with an arbitary  
server (needed access to files on a different machine than the HTTP  
server)  
  
however, all the confidential data can be sent in this manner.  
  
A more pertinent problem is that Java can dynamically load classes through  
a socket. The new code might exploit a security hole which was unknown at  
the time the applet was written - a company might assume that because an  
applet was written _before_ a security hole was found, it cannot exploit  
this hole, and therefore the company doesn't need to fix the hole. (i  
know, bad logic, but ...?)  
  
Tim  
http://stl.qucis.queensu.ca/~wright  
  
When in doubt, doubt. It's what set's us apart from the animals.  
(If you define animals as Politicians and Technocrats)  
  
------------------------------------------------------------------------  
  
Date: Fri, 12 Feb 1999 15:32:22 -0500  
From: Tim Wright <wright@qucis.queensu.ca>  
To: BUGTRAQ@netspace.org  
Subject: Applets listening on Sockets in Java  
  
<alx@acm.org> and I recently explored the "security hole" in Java  
where an applet can listen on a port, and accept connections from any  
machine, rather than just the machine from which the applet was  
down-loaded.  
  
The code which was posted to BugTraq does appear to exhibit this  
behavior. However, on closer inspection the posted code only created a  
class to listen on a socket, and did not call the method to accept  
connections from that socket. It turns out that the SecurityException is  
(correctly) thrown during the accept method call.  
  
The server and client code we used follow. It was tested in Netscape 4.06  
for WindowsNT. It is important to notice that we hard coded the machine  
which the applet would run into the client.  
  
Tim  
http://stl.qucis.queensu.ca/~wright  
  
There are no constants in life,  
only Variables which haven't changed their value in a while.  
  
There are no Variables in life,  
We life in a continuous stream of short lived constants.  
  
  
  
// the applet server - listens on the socket  
  
import java.applet.*;  
import java.awt.*;  
import java.io.*;  
import java.net.*;  
/**  
* This type was created in VisualAge.  
*/  
public class SocketListener extends Applet {  
  
/**  
* This method was created in VisualAge.  
*/  
public void init() {  
ServerSocket ss;  
try {  
ss = new ServerSocket(7000);  
} catch (IOException ioe) {  
System.err.println("error, cannot create socket");  
return;  
}  
System.err.println("created server socket");  
while (true) {  
try {  
System.err.println("waiting for connection");  
Socket s = ss.accept();  
System.err.println("accepted connection from "+s.getInetAddress());  
DataInputStream pr = new DataInputStream(s.getInputStream());  
System.err.println("read:"+ pr.readLine());  
pr.close();  
} catch (IOException ioe) {  
}  
}  
}  
}  
  
  
  
// the applet client - connects to the socket  
import java.net.*;  
import java.io.*;  
  
public class SocketConnector {  
  
public SocketConnector() {  
super();  
}  
  
public static void main(java.lang.String[] args) {  
try {  
Socket s=new Socket("stl.qucis.queensu.ca",7000);  
PrintWriter dot=new PrintWriter(s.getOutputStream());  
dot.print("hi there");  
s.close();  
}  
catch (Exception e) {  
System.err.println("exception occured");  
e.printStackTrace();  
}  
}  
}  
  
`