There used to be a security bug in HotJava, where the internel
certificate table (for mapping public signing keys to permisions) was
returned to an applet by an accessor method instead of a copy of the
table. This way an applet was not only able to read the permisions but
also to write back to the table. This way, the applet could put it's own
public key in a row that had plenty of permisions.
Now, this bug is fixed but an applet could subclass this fixed class and,
as it (unwantedly) has access to privat members it could malicously
overwrite the accessor method to return the table instead of a clone
again.
PLEASE NOTE! This bug was reconstructed from my memory. My description
might not exactly describe what was going on in this case and it might
not even have been HotJava but another product that was afected. This
Response is not meant to discredit Sun or HotJava.
Uli Luckas
>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 29.06.00, 23:25:41, schrieb Joseph Shraibman <[EMAIL PROTECTED]> zum
Thema Re: Security bug in a major fraction of VMs:
> And this is a big security problem? Access specifiers are meant to
> protect programmers from doing stupid things, not protect security. Of
> course if you hack the jvm you will be able to get access to a private
> field. So just what is the security concern here?
> Wolfgang Hoschek wrote:
> >
> > There is a serious security bug in a major fraction of VMs.
> > Some VMs do not check access specifiers at runtime. This allows you to
> > access private data with either a hacked compiler, direct editing of
> > byte code, or a simple recompile.
> > For details, see http://metalab.unc.edu/javafaq/
> >
> > I checked the mini program given there on a number of Linux and Solaris
> > VMs.
> >
> > "NOT OK" means the access specifiers are not checked at runtime
> > "OK" means they are checked and the runtime correctly refuses the class.
> >
> > Interestingly BlackdownRC4 with Inprise's jitter was "NOT OK" whereas
> > BlackdownRC4 with sunwjit SIGSEV'd which is also not quite ok.
> > Here the builds I checked:
> >
> > Solaris@Spars
> > ------------
> > - NOT OK: java version "1.3.0", Java Hotspot(TM) Client VM (build
> > 1.3-beta, mixed mode)
> > - OK: (IncompatibleClassChangeError) java version "1.2.2", Solaris VM
> > (build Solaris_JDK_1.2.2_05a, native threads, sunwjit)
> >
> > RedHat6.1@Intel
> > ------------
> > - NOT OK: java full version "JDK 1.1.8 IBM build l118-20000515 (JIT
> > enabled: jitc)"
> > - NOT OK: java version "1.2.2", Classic VM (build Linux_JDK_1.2.2_RC4,
> > nativethreads, javacomp)
> > - HALF OK (segmentation violation): java version "1.2.2", Classic VM
> > (build Linux_JDK_1.2.2_RC4, nativethreads, sunwjit)
> > - NOT OK: java version "1.3.0", Java(TM) 2 Runtime Environment, Standard
> > Edition (build 1.3.0), Classic VM (build 1.3.0, J2RE 1.3.0 IBM build
> > cx130-20000605 (JIT enabled: jitc))
> > - NOT OK: java version "1.3.0", Classic VM (build 1.3.0, J2RE 1.3.0 IBM
> > build cx130-20000502 (JIT enabled: jitc))
> > - NOT OK: java version "1.3.0beta1", Java(TM) 2 RuntimeEnvironment,
> > Standard Edition (build 1.3.0beta-b07), Java Hotspot(TM) Client VM
> > (build 1.3.0beta-b04, mixed mode)
> >
> > Cheers,
> > Wolfgang.
> >
> > ----------------------------------------------------------------------
> > To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> ----------------------------------------------------------------------
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
