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

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/

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.

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!