Date: Tue, 27 Feb 1996 10:38:03 GMT From: Jonathan Larmour <jlarmour@origin-at.co.uk> To: firewalls@GreatCircle.COM Subject: Java security risk (bypassing firewalls) Message-ID: <1.5.4b11.16.19960227104358.31171af0@gatekeeper>
next in thread | raw e-mail | index | archive | help
I picked this up from a friend. Its totally plausible and seems to affect anyone using Java behind a firewall. Any ideas on how to deal with it (apart from disallowing files with .cla or .class extensions at the proxy level)? The most I've done is recompile my bind with -DSUNSECURITY which should (hopefully) log any times when the reverse mapping does not match the name->IP mapping. Although, I'm not entirely sure that will help either. So, any ideas? >Date: Sun, 18 Feb 1996 23:57:02 -0500 >From: Drew Dean <ddean@CS.Princeton.EDU> >Subject: Java security problems > >We have discovered a serious security problem with Netscape Navigator's 2.0 >Java implementation. (The problem is also present in the 1.0 release of the >Java Development Kit from Sun.) An applet is normally allowed to connect >only to the host from which it was loaded. However, this restriction is not >properly enforced. A malicious applet can open a connection to an arbitrary >host on the Internet. At this point, bugs in any TCP/IP-based network >service can be exploited. We have implemented (as a proof of concept) an >exploitation of an old sendmail bug. > >If the user viewing the applet is behind a firewall, this attack can >be used against any other machine behind the same firewall. The >firewall will fail to defend against attacks on internal networks, >because the attack originates behind the firewall. > >The immediate fix for this problem is to disable Java from Netscape's >"Security Preferences" dialog. An HTTP proxy server could also >disable Java applets by refusing to fetch Java ".class" files. We've >sent a more detailed description of this bug to CERT, Sun, and >Netscape. > >A second, also serious, bug exists in javap, the bytecode >disassembler. An overly long method name can overflow a stack >allocated buffer, potentially causing arbitrary native code to be >executed. The problem is an unchecked sprintf() call, just like the >syslog(3) problem last year. Many such bugs were in the alpha 3 >release's runtime, but were carefully fixed in the beta release. The >disassembler bug apparently slipped through. This attack only works >on users who disassemble applets. The fix is to not run javap until >Sun releases a patch. > >Note that we've only had success in exploiting the first flaw on an SGI. >Windows 95 and DEC Alpha versions of Netscape have other bugs in their >socket implementations that make it harder (although not necessarily >impossible) to exploit the problem. This is the second time that unrelated >implementation bugs have prevented us from demonstrating security problems >in Java. > >http://www.cs.princeton.edu/~ddean/java will contain more information >soon, including a revised version of our paper, to appear in the 1996 >IEEE Symposium on Security and Privacy. > >Drew Dean <ddean@cs.princeton.edu> >Ed Felten <felten@cs.princeton.edu> >Dan Wallach <dwallach@cs.princeton.edu> > Department of Computer Science, Princeton University > >For more information, please contact Ed Felten, 609-258-5906, FAX >609-258-1771. 323 Cambridge Science Park, Origin UK, Cambridge, England. CB4 4WG. Tel: +44 (1223)-423355 Fax: +44 (1223)-420724 E-mail: guess... Disclaimer: This is not a disclaimer
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1.5.4b11.16.19960227104358.31171af0>