full-disclosure - Re: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <A7F74BDC-4FBE-4971-AEAE-3E23F16A4507@corsaire.com>
Date: Mon Mar 27 16:21:51 2006
From: stephen at corsaire.com (Stephen de Vries)
Subject: Re: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L]
	4 Questions: Latest IE vulnerability, Firefox vs IE security,
	Uservs Admin risk profile,
	and browsers coded in 100% Managed Verifiable code

On 27 Mar 2006, at 11:02, Jeff Williams wrote:

>
>> I am not a Java expert, but I think that the Java Verifier is NOT  
>> used on
> Apps that >are executed with the Security Manager disabled (which I  
> believe
> is the default >setting) or are loaded from a local disk (see "...  
> applets
> loaded via the file system >are not passed through the byte code  
> verifier"
> in http://java.sun.com/sfaq/)
>
> I believe that as of Java 1.2, all Java code except the core  
> libraries must
> go through the verifier, unless it is specifically disabled (java
> -noverify).

I had the 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.   
I tested this by compiling 2 classes where one accesses a public  
member of the other.  Then recompiled the other and changed the  
method access to private.  Tested on:
Jdk 1.4.2 Mac OS X
Jdk 1.5.0 Mac OS X
Jdk 1.5.0 Win XP

all behave the same.

[~/data/dev/applettest/src]java -cp . FullApp
Noone can access me!!
[~/data/dev/applettest/src]java -cp . -verify FullApp
Exception in thread "main" java.lang.IllegalAccessError: tried to  
access field MyData.secret from class FullApp at FullApp.main 
(FullApp.java:23)

Using the same code with an Applet loaded from the filesystem throws  
an IllegalAccessError exception as it should.

-- 
Stephen de Vries
Corsaire Ltd
E-mail: stephen@...saire.com
Tel:	+44 1483 226014
Fax: 	+44 1483 226068
Web: 	http://www.corsaire.com