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."

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

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.

the REAL question is...

How well do these stand up under load, and should /. replace Apache? :)

Seriously, I think the biggest issue will be a non-interactive thing that can be emailed to anyone, instead of this consent-to-opening-form thing. Because netscape is only open for a short time, a real proper exploit would have to make an outbound connection to a preset IP to "check-in" that it's available.

--

Re:Why is exploit being promulgated immediately?

CERT (it stands for computer emergency response team) was notified shortly before they downloaded the code more than 24 hours before it was announced on Slashdot or posted to USENET -- not that such a professional courtesy carries the force of law. It is all dependent on reciprocation and good faith behavior on the part of all parties involved. For example, if CERT were to take the information and disclose it to a third party who CERT then gives credit for discovering the exploit, this would result in a reasonable man ceasing to provide CERT with advanced notice in the future for obvious reasons.

In point of fact, something of this nature has occured as previously documented by Dan. It may not be Christian for Dan to fail to endlessly forgive transgressions and abuses of his trust, but then I thought business was about reciprocal altruism, not simply continuing to do favors for those who demonstrate a track record of abusing your trust.

If the force of law is to apply here, would it not make sense to prosecute the responsible parties at CERT, or wherever, if they abuse the professional courtesy extended them by people from around the world (not just in the United States) since, having been granted a unique position of public trust and authority, the abuse of said public trust and authority (for example, failing to respond as their name "emergency response" would suggest) subjects the global public to far greater dangers than a "premature" disclosure by one grey hat?

The grey hats of the world do not exist for the convenience of flabby and possibly corrupt bureaucrats -- nor should the web users of the world have to wait for the flabby and possibly corrupt bureaucrats to possibly notify their corrupt cronies of exploits so that maximum criminal profits may be extracted, whether through plagerism or direct criminal activity.

Oh, but there I go being paranoid about the government again. ;-)

Works also with blackdown Java plugin

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

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

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...

netscape server obsolete?

great! i'll email my boss to tell them we dont need that fancy shmansy netscape webserver anymore! it's bundled with communicator

and you people mocked netscape. shows you all.

and i guess with mozilla, they'll be able to completely take over my computer, seeing how it will be an entire platform for doing everything...

Re:Works also with blackdown Java plugin

You need a -p tcp in there as -y doesn't work without it (according to the man page). Oh, and have fun making local connections ;)

That said, thanks for the -y info. I was wondering if I could do that and hadn't gotten around to browsing the man page yet.

Re:Here's why it works

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.

Read Risks Forum, CERT

This brings up yet another opportunity from me to recommend that you read The Forum on Risks to the Public in Computers and Related Systems [ncl.ac.uk] also available on the Usenet News as comp.risks [comp.risks].

You need to read Risks if you:

• Use and depend on computers in any but the most trivial way
• Program computers
• Make policy decisions regarding computers
• Operate computers in a way that affects safety (pilot a modern airplane, work in a hospital)
• Use computers in a way that may impact your own safety (flown on a modern airplane lately?)

I think that probably covers most Slashdot readers, which is why I keep posting it here.

You might also want to check out the book "Computer Related Risks" by forum moderator Peter G. Neumann ISBN 020155805X. It draws on material from the forum but discusses it in greater depth. You'll find it at all the online bookstores and many local bookstores as well.

Here's a few of my own posts to Risks:

The Sinking of the USS Gitarro [ncl.ac.uk]

A US Navy submarine was sunk in the Mare Island channel near Vallejo, California by a test technician. He was trying to level the ship to run a test, and only knew how to take in ballast water, not expel it. The forward sonar hatch was off, power cables were run through the pressure safety doors because the sub was in for repairs, and so the might Gitarro sunk. My dad was stationed at the shipyard at the time, back in the 60's.

Algorithms Have Unclear Boundaries [ncl.ac.uk]

Copy of a letter I wrote the patent office, on the problem of defining what is or is not an algorithm in a program when the boundaries between them cannot be precisely defined. Discussed the problems that occur when the virtual machine breaks down (as I guess happens in this case).

Excel Linked Spreadsheet Bug [ncl.ac.uk]

In which a friend of mine bounced a business check for four thousand dollars because of a bug in Microsoft Excel - a bug he could later demonstrate at will.

I also recommend that everyone refer regularly to the CERT Coordination Center [cert.org] to read the latest in security advisories and report security problems to them when you find them.

Tilting at Windmills for a Better Tomorrow

Re:Glad I run Netscape from behind a firewall.

Here's another warez and pr0n site:

warez.slashdot.org [slashdot.org]

enjoy!

Slashdot is a good beta test site for a crack

Now after a good night's testing by the Slashdot community, with posting of which version numbers work and which don't, which OSes work and which don't, whether it matters that some other service is using the default port and the effect of firewalls and IP masquerading and so on, somebody who wanted to really use this for evil ends can now be well-armed with the information they need to make not just an effective exploit, but a reliable one as well!

Is this Java Security Model or Implementation?

It makes a lot of difference - the Java security model is supposed to prevent this kind of thing from happening, and I'm not aware of previous cracks of the model itself. Cracks of Netscape's implementation of the security model are a different issue - there have been problems before, and there may be others in the future, but they don't mean there's something fundamentally wrong with executable-in-a-sandbox scripting languages. Or is this something that wasn't a hole in Java 1.0 but has been broken between then and now?

Obviously non-sandboxed scripting languages like Javascript and ActiveX are a different kind of risk, and simply can't be trusted.

Re:Strangeness...

No, /etc/services does not disable any traffic over a particular port. The most it will do is prevent the getservbyname(3) family of function calls from working. /etc/services is just a file that translates between names and numbers. Nothing else is magic about it at all. Are you just trolling for newbies or what?

Re:Unbelievable,... or not?

It is only a matter of time before the MS marketing people will find a way to leverage the constant finding/fixing issues in MS products versus the lack of any searching for holes in Open Source products.

So are you a troll, or just ignorant?

Last time I checked Bugtraq there were a whole bunch of people searching through all sorts of open source software for holes, and reporting them.

Last time I looked at www.openbsd.org, it had done a thourough review of any potential security holes in their open source operating system.

And last time I checked, neither the Netscape 4.x browser nor its Java component were Open Source.

Steven E. Ehrbar

Re:Wow

I think I'll just stick to Lynx.

Re:Works also with blackdown Java plugin

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

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

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.

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

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!

Re:So who would run Netscape as root?

Under *nix, yer stil pretty safe. Only running Netscape as root would truly expose you. And no one is stupid
enough to do that, right? Well... maybe Red Hat users.

Actually, netscape is used as the UI to a number of sysadmin utils including up2date. (And, yes, it does run netscape as root.)

NFS

Is it me or does this seem easier to setup than editing /etc/vfs/vfstab to export /export/blah - now if only we could get NIS to adopt this for automounts we'd be set for NIS on a WAN !!! (except for the minor issue that anyone can read a file - but life has it's trade offs....)