| Kevin is correct, a type confusion attack will allow the bypass of the
| security manager simply because via a type confusion attack you will be
able
| to change what the security manager is 'seeing'
|
| So in an environment where you have a solid Security Policy (enforced by a
| Security
On 5/14/06, Dinis Cruz <[EMAIL PROTECTED]> wrote:
Kevin is correct, a type confusion attack will allow the bypass of the
security manager simply because via a type confusion attack you will be able
to change what the security manager is 'seeing'
In both .Net and Java, the sandboxes logic (CAS a
bersecurity advisor, Richard Clarke,
at eWeek Security Summit
-Original Message-
From: [EMAIL PROTECTED] on behalf of Gary McGraw
Sent: Sat 5/13/2006 4:42 PM
To: Stephen de Vries; Dinis Cruz
Cc: Secure Coding Mailing List
Subject: Re: [SC-L] By default, the Verifier is disabled
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
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 dir
On 12 May 2006, at 14:58, Dinis Cruz wrote:
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
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]. Exception
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 wh
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
Securin
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:
http://ja
Tim Hollebeek wrote:
$ 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) # Problemat
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 M
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 "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 wro
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 -ve
Michael Silk wrote:
> On 5/9/06, Dinis Cruz <[EMAIL PROTECTED]> wrote:
>
>> 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. You
ter in Securing Java
www.securingjava.com.
gem
www.swsec.com
-Original Message-
From: Wall, Kevin [mailto:[EMAIL PROTECTED]
Sent: Mon May 08 19:17:22 2006
To: Dinis Cruz; Stephen de Vries
Cc: Secure Coding Mailing List
Subject: RE: [SC-L] By default, the Verifier is disabled on
On 5/9/06, Dinis Cruz <[EMAIL PROTECTED]> wrote:
Jeff Williams wrote:
>
> But Dinis is right. There is a real problem with verification, as
> demonstrated in the message below. This is a clear violation of the
> Java VM Spec, yet my messages to the team at Sun developing the new
> verifier have b
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 t
EMAIL PROTECTED]
Sent: Mon May 08 19:17:22 2006
To: Dinis Cruz; Stephen de Vries
Cc: Secure Coding Mailing List
Subject: RE: [SC-L] By default, the Verifier is disabled on .Net and Java
Dinis Cruz writes...
> Stephen de Vries wrote:
> > Java has implemented this a bit differ
Dinis Cruz writes...
> 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 trust), but it co
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 trust), but it could still be vulnerable to type confusi
Jeff Williams wrote:
But Dinis is right. There is a real problem with verification, as
demonstrated in the message below. This is a clear violation of the
Java VM Spec, yet my messages to the team at Sun developing the new
verifier have been ignored. And it’s a real issue, given the number of
ject: Re: [SC-L] By default, the Verifier is disabled on .Net and Java
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 h
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
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
Jeff Williams wrote:
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 variab
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 http://www.
> $ 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 [
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
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 ve
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 with
David Eisner wrote:
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
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(
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 i
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
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.
>>
On 3 May 2006, at 06:48, Dinis Cruz wrote:
Here is a more detailed explanation of why (in my previous post) I
said: "99% of .Net and Java code that is currently deployed is
executed on an environment where the VM verifier is disabled, ."
--
In .Net the verifier (the CLR f
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 Secur
[Moderator: Feel free to discard some or all of Dinis' original post
below.
I wasn't sure how much to trim because I don't know how
much people have been paying attention to this particular
discussion and I didn't want them to loose context and have
t
42 matches
Mail list logo
