Bugtraq mailing list archives
Re: New Java Security Flaw Found
From: garagan () BORG CS DAL CA (Sean Garagan)
Date: Mon, 20 Jul 1998 22:25:58 -0300
Hi all, I thought this when I first read this report, but I then realized that the report is a bit poorly written. It describes a bug in Netscape's Java implementation that allows an attacker take advantage of the ClassLoader class in java.lang. The problem with ClassLoader is it when a program extends ClassLoader, it has no built in protection for the core Java classes. The Java team assumes that when you make your own ClassLoader, you will add checks to see if a class is in java.* and load the local copy using findSystemClass(). This also means that you can replace the core Java classes by putting your own in the classpath before the actual ones, so if your application allows you to specify the classpath, you can do whatever you want. I was actually quite surprised to see this when I wrote a ClassLoader a while ago. I had wrongly assumed Sun would hard code checks for the core Java classes. It looks like Sun relies on proper security implementations to prevent the ClassLoader from being replaced. Sean On Sat, Jul 18, 1998 at 04:49:25PM -0500, Greg Alexander wrote:
Is it appropriate to call a java implementation-related security hole a java hole? That'd be like calling a bug in pine a bug in internet e-mail. On Fri, 17 Jul 1998, Gary McGraw wrote:Hello all, Princeton's Safe Internet Programming Team recently announced the discovery of a serious Java security hole that can be leveraged into an attack applet. Their description follows: ------------------------------------------------------------------------ We have found another Java security flaw that allows a malicious applet to disable all security controls in Netscape Navigator 4.0x. After disabling the security controls, the applet can do whatever it likes on the victim's machine, including arbitrarily reading, modifying, or deleting files. We have implemented a demonstration applet that deletes a file.<clip> Greg Alexander - also <galexand () indiana edu> - http://sietch.home.ml.org/ ---- Any sufficiently advanced bug is indistinguishable from a feature. -- Rich Kulawiec Any sufficiently advanced feature is indistinguishable from a bug. -- Greg's corollary
Current thread:
- Re: EMERGENCY: new remote root exploit in UW imapd, (continued)
- Re: EMERGENCY: new remote root exploit in UW imapd Alec Kosky (Jul 16)
- Re: EMERGENCY: new remote root exploit in UW imapd Kragen (Jul 17)
- Buffer overflows. was Re: EMERGENCY: new remote root exploit in Craig Spannring (Jul 17)
- Re: Buffer overflows. was Re: EMERGENCY: new remote root exploit Geoffrey KEATING (Jul 19)
- Re: EMERGENCY: new remote root exploit in UW imapd FanLi Tai (Jul 18)
- Re: EMERGENCY: new remote root exploit in UW imapd Brett Lymn (Jul 19)
- SECURITY: imap-4.1.final now available twiztah (Jul 16)
- Verity/Search'97 Security Problems Jay Soffian (Jul 16)
- New Java Security Flaw Found Gary McGraw (Jul 17)
- Re: New Java Security Flaw Found Greg Alexander (Jul 18)
- Re: New Java Security Flaw Found Sean Garagan (Jul 20)
- Fwd: Security warning: Netscape 4.0x https & Squid 1.2beta proxy Fred Donck (Jul 20)
- N-Base Vulnerability Advisory TTSG (Jul 20)
- IRIX 6.4 ioconfig(1M) and disk_bandwidth(1M) Vulnerability SGI Security Coordinator (Jul 20)
- IRIX 6.3 & 6.4 mailcap vulnerability SGI Security Coordinator (Jul 20)
- Bounds Checking Aleph One (Jul 20)
- Re: Bounds Checking Ari Heitner (Jul 21)
- Re: Bounds Checking Andrew McNaughton (Jul 21)
- Re: New Java Security Flaw Found Greg Alexander (Jul 18)
- Re: EMERGENCY: new remote root exploit in UW imapd Andy Church (Jul 17)
- Re: EMERGENCY: new remote root exploit in UW imapd Kragen (Jul 21)
- Re: EMERGENCY: new remote root exploit in UW imapd Craig Spannring (Jul 21)
- Re: EMERGENCY: new remote root exploit in UW imapd Kragen (Jul 21)