Date: Tue, 2 Feb 1999 13:42:32 -0800 From: Giao Nguyen 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 To: BUGTRAQ@netspace.org Subject: Re: Unsecured server in applets under Netscape Date: Tue, 2 Feb 1999 13:42:32 -0800 From: Giao Nguyen 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 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? ------------------------------------------------------------------ ------------------------------------------------------------------ [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 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 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 To: BUGTRAQ@netspace.org Subject: Re: open socket in java nino worte: > > 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 ! > 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 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 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 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 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 To: BUGTRAQ@netspace.org Subject: Applets listening on Sockets in Java 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(); } } }