From owner-freebsd-security Wed Feb 28 06:37:47 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA11623 for security-outgoing; Wed, 28 Feb 1996 06:37:47 -0800 (PST) Received: from sivka.carrier.kiev.ua (root@sivka.carrier.kiev.ua [193.125.68.130]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA11501 for ; Wed, 28 Feb 1996 06:34:35 -0800 (PST) Received: from elvisti.kiev.ua (uucp@localhost) by sivka.carrier.kiev.ua (Sendmail 8.who.cares/5) with UUCP id QAA22946 for security@freebsd.org; Wed, 28 Feb 1996 16:32:21 +0200 Received: from office.elvisti.kiev.ua (office.elvisti.kiev.ua [193.125.28.33]) by spider2.elvisti.kiev.ua (8.6.12/8.ElVisti) with ESMTP id MAA23809 for ; Wed, 28 Feb 1996 12:15:38 +0200 Received: (from stesin@localhost) by office.elvisti.kiev.ua (8.6.12/8.ElVisti) id MAA01148 for security@freebsd.org; Wed, 28 Feb 1996 12:15:37 +0200 Received: from spider2.elvisti.kiev.ua (spider2.elvisti.kiev.ua [193.125.28.35]) by office.elvisti.kiev.ua (8.6.12/8.ElVisti) with ESMTP id FAA11658 for ; Wed, 28 Feb 1996 05:54:37 +0200 Received: from sivka.UUCP (uucp@localhost) by spider2.elvisti.kiev.ua (8.6.12/8.ElVisti) with UUCP id FAA16409 for stesin@elvisti.kiev.ua; Wed, 28 Feb 1996 05:51:04 +0200 Received: from kiae.UUCP (uucp@localhost) by sivka.carrier.kiev.ua (Sendmail 8.who.cares/5) with UUCP id FAA05076 for stesin@elvisti.kiev.ua; Wed, 28 Feb 1996 05:00:56 +0200 Received: by sequent.KIAE.su (UUMAIL/2.0); Wed, 28 Feb 96 05:30:52 +0300 Received: by kremvax.demos.su (uumail v3.2.2/D) for stesin@elvisti.kiev.ua; Wed, 28 Feb 1996 05:21:30 +0300 Received: by kremvax.demos.su (8.6.12/D) from relay5.UU.NET [192.48.96.15] for with ESMTP id FAA04246; Wed, 28 Feb 1996 05:21:29 +0300 Received: from miles.greatcircle.com by relay5.UU.NET with ESMTP id QQaeur23493; Tue, 27 Feb 1996 21:20:37 -0500 (EST) Received: (majordom@localhost) by miles.greatcircle.com (8.7.1-lists/Lists-951222-1) id CAA09762 for firewalls-outgoing; Tue, 27 Feb 1996 02:57:43 -0800 (PST) Received: from gatekeeper.origin-at.co.uk (gatekeeper.origin-at.co.uk [194.130.16.17]) by miles.greatcircle.com (8.7.1/Miles-951221-1) with SMTP id CAA09757 for ; Tue, 27 Feb 1996 02:57:31 -0800 (PST) Received: from mailhost (pc158.origin-at.co.uk [194.130.16.158]) by gatekeeper.origin-at.co.uk (8.6.12/8.6.12) with SMTP id KAA14152 for ; Tue, 27 Feb 1996 10:38:03 GMT Date: Tue, 27 Feb 1996 10:38:03 GMT Message-Id: <1.5.4b11.16.19960227104358.31171af0@gatekeeper> X-Sender: jlarmour@gatekeeper X-Mailer: Windows Eudora Light Version 1.5.4b11 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: firewalls@GreatCircle.COM From: Jonathan Larmour Subject: Java security risk (bypassing firewalls) Sender: owner-security@FreeBSD.ORG Precedence: bulk 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 >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 >Ed Felten >Dan Wallach > 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