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();
}
}
}