in reply to
Dinis Cruz dinis at ddplus.net
Sun May 14 03:40:20 EDT 2006
...skipped...
So in an environment where you have a solid Security
Policy (enforced by
a Security Manager) but the verifier is NOT enabled,
then to jump out of
the sandbox all that you need to do is to create a
Type
On 12 May 2006, at 09:10, Charles Miller wrote:
It's not reflection: you're confusing IllegalAccessException and
IllegalAccessError.
For any non-Java nerd still listening in: there are two fundamental
types of Throwable exception-conditions in Java: Exceptions and
Errors[1]. Exceptions
Stephen,
I think the reason you get the IllegalAccessError is because the VM
thinks you are loading from a remote url.
I don't think the user of a classloader per-se forces the
verification of the class. (I wrote a class loader like yours that
just loads a file with no package in the current
Shall we ask ed felten to did out the old type confusion toolkit?
gem
-Original Message-
From: Stephen de Vries [mailto:[EMAIL PROTECTED]
Sent: Sat May 13 15:12:48 2006
To: Dinis Cruz
Cc: Secure Coding Mailing List
Subject:Re: [SC-L] By default, the Verifier is
Michael Silk wrote:
You can't disable the security manager even with the
verifier off. But
you could extend some final or private class that the security manager
gives access to.
This is not correct. With the verifier disabled there are multiple ways
you can jump out of the Security
Michael Silk wrote:
"What is the point of the verifier?' , 'Why
use it? and 'What are the
real security advantages of enabling the verifier if the code is
executed in an environment with the security manager disabled?'
Huh? You can find what it does here:
Gary McGraw wrote:
The switch from applets vs applications security to trusted code vs untrusted
code happened with the introduction of jdk 1.1 (way back when). Ed and I followed the sun
marketing lead in 96 when it came to applets vs applications, but we cleared this up later in
Securing
On 5/12/06, Dinis Cruz [EMAIL PROTECTED] wrote:
Michael Silk wrote:
What is the point of the verifier?' , 'Why use it? and 'What are the
real security advantages of enabling the verifier if the code is
executed in an environment with the security manager disabled?'
Huh? You can find what
Michael Silk wrote:
On 5/9/06, Dinis Cruz [EMAIL PROTECTED] wrote:
snip
Is there a example out there where (by default) java code is executed in
an environment with :
* the security manager enabled (with a strong security policy) and
* the verifier disabled
Yes. Your local
Stephen de Vries wrote:
With application servers such as Tomcat, WebLogic etc, I think we have a
special case in that they don't run with the verifier enabled - yet they
appear to be safe from type confusion attacks. (If you check the
startup scripts, there's no mention of running with
The verifier is enabled via the commandline. It is either on or off.
the VM does other forms of verification though.
http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#79383
...
-- Michael
On 5/11/06, Jeff Williams [EMAIL PROTECTED] wrote:
Stephen de Vries wrote:
Michael Silk wrote:
The verifier is enabled via the commandline. It is either on or off.
I'm not sure that's true. See:
http://securecoding.org/pipermail/sc-l/2006/000262.html
Summary: there are *three* comandline options: -verify, -noverify, and
-verifyremote. It is -verifyremote that
The switch from applets vs applications security to trusted code vs
untrusted code happened with the introduction of jdk 1.1 (way back when). Ed
and I followed the sun marketing lead in 96 when it came to applets vs
applications, but we cleared this up later in Securing Java
That's essentially correct kevin. The idea was to be able to run not remote,
but untrusted code. Note that modern readers will understand that local code
can be untrusted. There is a good picture of this in securing java.
gem
-Original Message-
From: Wall, Kevin [mailto:[EMAIL
On 5/9/06, Dinis Cruz [EMAIL PROTECTED] wrote:
Stephen de Vries wrote:
Java has implemented this a bit differently, in that the byte code
verifier and the security manager are independent. So you could for
example, run an application with an airtight security policy (equiv to
partial
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
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
Wall, Kevin wrote:
Also, from the results of your test, it seems to indicate that SOME TYPE
of verification is taking place, but if all you did was change a few
ARBITRARY bytes in the .class file, I don't think that proves the
byte code verifier is being being run in it's entirety.
I agree
On 5/4/06, Dinis Cruz [EMAIL PROTECTED] wrote:
Wall, Kevin wrote:
Also, from the results of your test, it seems to indicate that SOME TYPE
of verification is taking place, but if all you did was change a few
ARBITRARY bytes in the .class file, I don't think that proves the
byte code
Dinis Cruz wrote:
Ok, I just did some further tests and I think I can say that Java
(version 1.5.0_06) has similar verification issues to the ones I
discovered on the .Net Framework (see links in my previous post).
[...]
This should prove that the verifier is not enabled by default on java
$ java -cp . -noverify HelloWorld
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x6d7415fb,
pid=3512, tid=2260 # # Java VM: Java HotSpot(TM) Client VM
(1.5.0_06-b05 mixed mode) # Problematic frame:
# V
I'm psyched about this thread. Rock on guys.
For those of you who may need some basics, you might want to read
Securing Java (a book I wrote with Ed Felten in 1999...the first edition
in 1996 was called Java Security). The book is available completely for
free in searchable format at
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
Wall, Kevin wrote:
same intuition about the verifier, but have just tested
this and it is not the case. It seems that the -noverify is the
default setting! If you want to verify classes loaded from the local
filesystem, then you need to explicitly add -verify to the cmd line.
David Eisner wrote...
Wall, Kevin wrote:
The correct attribution for bring this up (and the one whom you are
quoting) is Dinis Cruz.
same intuition about the verifier, but have just tested
this and it is not the case. It seems that the -noverify is the
default setting! If you want to
Ok, I just did some further tests and I think I can say that Java
(version 1.5.0_06) has similar verification issues to the ones I
discovered on the .Net Framework (see links in my previous post).
Here is a full description of my test (which is a variation of the one
done by Stephen de Vries
Verifier in 1.5 is definately OFF by default:
to confirm this do the following:
1. Create this class:
==
public class Foo {
public static int k = 23;
static {
System.out.println(initially k: + k);
}
public static void m(){
System.out.println(m()
29 matches
Mail list logo
