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]
