Java Security Hole Makes Netscape Into Web Server

Baldrson and other folks as well write: "Dan Brumleve is at it again with Brown Orifice. In this episode, our fearless grey hat opens a security hole in the Web's foundation that makes Napster look positively tame by comparison. Be careful with this, kids. It turns your Netscape Web browser into a Web server that can serve up your entire file system to any other Web browser."

Comments

Netscape hasn't been any good for the last 5 years

[BenJeremy]

Not a troll... just a statement of my observations... I resisted switching to IE for a few years, but I got fed up with all the countless bugs and resource/memory leaks (which were NEVER fixed, even after I properly reported reproducable bugs).

Now this. Netscape's browser was merely a platform to sell Netscape's server software. They only complained about IE when M$ started giving away IIS with NT - and then got really loud when IE surpassed Communicator in features and support (that's right... M$ might have had a few security leaks to fix, but they usually responded swiftly). Netscape often gets a lot less scrutiny compared to M$' browser, too, I might add.

Netscape sucks. A one hit wonder that now ranks below M$ and others in browser and server software.

Works also with blackdown Java plugin

[Jeffrey Baker]

I tested this with NN 4.74 and the Blackdown Java Plugin 1.2.2 Final. The exploit also works against this combination, so it isn't limited to the Java plugin that is shipped by default.

Every day I raise up thanks for ipchains(8):

ipchains -A input -l -y -j REJECT

Re:Works also with blackdown Java plugin

[Juergen Kreileder]

No, the plug-in is *not* vulnerable. The plug-in only gets activated when the HTML code uses a special tag (not by a plain applet tag).
Also, the exploit uses classes from netscapes java40.jar (netscape.net.URLConnection and netscape.net.URLInputStream), these classes are *not* available in the plug-in.

Juergen
--
Juergen Kreileder, Blackdown Java-Linux Team
http://www.blackdown.org/java-linux.html
JVM'01: http://www.usenix.org/events/jvm01/

who said this is a bad thing? (well, entirely bad)

[farkinga]

Granted, the brown office server source code could be modified to make all of the files on your computer publically accessable but the "bug" can be potentially useful as well. Well, obviously, it can be a free webserver and ftp server while taking up little more space than netscape itself. I wonder how many other bloatware applications can be exploited to do productive things? Or, how many other uses are there for Netscape? How many different language interpreters does it have? Java, Javascript, HTML, soon XML... Add to that its ability to use plugins, its ability to generate user intefaces on the fly, its internet connectivity, and you have a very rich set of resources to hack into other applications. Still, this is a bug and it can be exploited...

Re:Here's why it works

[bgalehouse]

Ok. W.R.T the second exception, and looking at the Sun JDK 1.3 source, I think Sun has fixed it in recent versions. But I also think I see what likely happened wrong in the earlier version.

the enlightening method, from ServerSocket is:

protected final void implAccept(Socket s)
throws IOException {
try {
s.impl.address = new InetAddress();
s.impl.fd = new FileDescriptor();
impl.accept(s.impl);
SecurityManager security =
System.getSecurityManager();
if (security != null) {
security.checkAccept(s.impl.getInetAddress().get HostAddress(),
s.impl.getPort());
}
} catch (IOException e) {
s.impl.close();
throw e;
} catch (SecurityException e) {
s.impl.close();
throw e;
}
}

Basically, you can't easily not do the open, because you need to get the port and host address from the impl attribute of the socket - after telling it to open. I think that a more sound approach would be to make impl flexible enough to do it's dns setup without actually opening.

Anyway though, the upshot is that the current approach requires that we trust the close method on impl. Looking back through the initializers which create impl, I think this is safe, but hard to prove safe. My guess is that the earlier JVM classes did this incorrectly - they trusted s.close instead of s.impl.close. Which is bad; we don't know where s has been.

Re:Not really a problem

[GrEp]

I have to disagree. Java itself is not the problem. This summer I have been doing a lot of Java development on Linux, and not once has Java crashed on me unless I wrote some bad code. The problem is netscape. The reason java crashes in your web browser has a lot more to do with the browser than the JVM.

Not really a problem

[blakestah]

This is a no brainer.

A Java based exploit can turn netscape browser into a server.

That oughta last about 3 seconds until Java locks up the netscape process.

Most Windows people have no idea how pathetically unstable Java for linux is.

That is the stupidest thing I've ever heard.

[Denial of Service]

Anyway, there's a really good reason why you shouldn't use "Internet Explorer", no matter how absolutively wounderful it is: you're voting with every mouseclick, leaving trails in the logs of every website you visit, getting us all a little closer to a Microsoft dominated world.

What a colossal load of absolute crap. First off, I am as pro-open source as anyone else, but this type of fanaticism makes me sick. You're telling me I should use a product that has been essentially forgotten by its creators to further political goals? No frigging way. I loathe Microsoft for everything they stand for, and I don't trust their product as far as I can throw it, but there is no damn way I will use a substandard product just to spite them. I run a weblog and ditched Netscape after losing my seventh article due to an unexpected and completely random bail, so if by switching to a clearly superior product that actually matters to its developers I am nurturing the tool of Satan, then I'm happy to do so.

It's ridiculous statements like yours that give OSS proponants a bad name, because by your own admission, quality of product has absolutely no meaning as long as you're screwing Bill in the process. Since when do OSS pundits argue for the purchase of commercial software like Opera? Sounds like pure politics to me. And guess what, I do develop for IE more than anything else simply because the viable alternatives either expect me to shell out hard earned cash I don't have, or have neglected the product to the point of borderline uselessness. Opera makes a great browser that nobody will ever know about because it's commercial software with free alternatives.

Netscape's outright loss in the web browser war has less to do with Microsoft's monopoly than it does AOL's complete neglect of a once desirable product, and if NS6 PR1 is any indication, nothing has changed. Standards compliance means precisely jack if the damn thing is slow, crashy or just plain unusable for any combination of reasons.

I hope you enjoy playing politician while the vast majority make choices based upon quality of product.

Here's why it works

[greg_barton]

This exploit is possible because of two factors.

The first problem is that Netscape's SecurityManager does not throw a SecurityExecption when the BOServerSocket constructor creates a java.net.ServerSocket. Here's the exception thrown in IE:

*******************************
com.ms.security.SecurityExceptionEx[BOServerSock et.]: cannot access 8080
at com/ms/security/permissions/NetIOPermission.check
at com/ms/security/PolicyEngine.deepCheck
at com/ms/security/PolicyEngine.checkPermission
at com/ms/security/StandardSecurityManager.chk
at com/ms/security/StandardSecurityManager.checkListe n
at java/net/ServerSocket.
at java/net/ServerSocket.
at BOServerSocket.
at BOHTTPD.init
at com/ms/applet/AppletPanel.securedCall0
at com/ms/applet/AppletPanel.securedCall
at com/ms/applet/AppletPanel.processSentEvent
at com/ms/applet/AppletPanel.processSentEvent
at com/ms/applet/AppletPanel.run
at java/lang/Thread.run
***********************************

After the ServerSocket is created, a SecurityException _is_ thrown whenever the BOServerSocket calls implAccept, but this Exception is easily caught. Also, by the time the Exception is thrown, the damage is already done. Here's the Exception:

************************************
netscape.security.AppletSecurityException: security.Couldn't connect to '127.0.0.1' with origin from '216.61.198.249'.
at java.lang.Throwable.(Compiled Code)
at java.lang.Exception.(Compiled Code)
at java.lang.RuntimeException.(Compiled Code)
at java.lang.SecurityException.(Compiled Code)
at netscape.security.AppletSecurityException.(Compile d Code)
at netscape.security.AppletSecurityException.(Compile d Code)
at netscape.security.AppletSecurity.checkConnect(Comp iled Code)
at netscape.security.AppletSecurity.checkConnect(Comp iled Code)
at netscape.security.AppletSecurity.checkConnect(Comp iled Code)
at netscape.security.AppletSecurity.checkAccept(Compi led Code)
at java.lang.SecurityManager.checkAccept(Compiled Code)
* at java.net.ServerSocket.implAccept(Compiled Code)
at BOServerSocket.accept_any(Compiled Code)
at BOHTTPD.run(Compiled Code) at java.lang.Thread.run(Compiled Code)
************************************

So, to recap: 1) Netscape does not throw a SecurityException when a ServerSocket is created in BOServerSocket., and 2) the connection is made by the time the exception is thrown in ServerSocket.implAccept().

#1 is Netscape's fault. They haven't implemented their security policies correctly, specifically that a ServerSocket can't listen on a port in an unsecure applet. #2 is definately Sun's fault because the SecurityException can easily be circumvented by overloading Socket.close().

Bravo to the grey hat for finding this!