Tim Hollebeek wrote:
The fact that editing the .class file allows you to produce one that
causes the JVM to crash is pretty strong evidence the verifier was
NOT used to validate the file.
Right. What follows is a summary of what we know so far, and what I
think is going on. The details
Two important clarifications for Java (based on my experiments):
1) The verifier IS enabled for the classes that come with the Java
platform, such as those in rt.jar. So, for example, if you create a class
that tries to set System.security (the private variable that points to the
I noticed quite a lot of Linux distros have already patched this or are as I
write. Do not know if X Org has yet but remember a post by Securnia about
this a day or so.
Regards,
George
Greenarrow1
InNetInvestigations-Forensic
- Original Message -
From: Kenneth R. van Wyk [EMAIL
Jim Halfpenny on the Webappsec list has discovered that BEA's JRockit
JDK _does_ use verification by default, his complete post quoted below
(the test was to access private methods on a class):
Hi,
BEA JRockit verifies by default and as far as I am aware does not offer a
-noverify option.
$
David Eisner wrote:
snip some good research
What determines when access to a private member is illegal? Is it, in
fact, the bytecode verifier?
Yes, it's done by the fourth pass of the verifier as described here:
http://java.sun.com/sfaq/verifier.html#HEADING13
Interestingly, Sun have
At 11:12 AM -0400 5/4/06, Kenneth R. van Wyk wrote:
Content-Type: multipart/signed; boundary=nextPart1887150.2DlSXmIMA5;
protocol=application/pgp-signature; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Stories about this (below) X bug and the DHS-sponsored project that found it
