I saw an interesting Wall Street Journal article today that talks about
companies adopting software security practices. Complete story can be found
at:
http://online.wsj.com/public/article/SB114670277515443282-B59kll7qXrkxOXId1uF0txp8NFs_20070504.html?
The article cites a couple of companies t
An interesting experiment on cracking verifiers was performed about ten years
ago by brian bershad at the university of washington. The paradigm used
comparative testing on multiple verifiers to find discrepancies.
This is covered in securing java as well.
Funny how I became interested in so
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
David Eisner wrote:
>
> 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 posted a contest to try a
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.
$ jav
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 PR
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
SecurityManag
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 detail
