Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

[Full-disclosure] Re: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Qu

Subject: [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
Date: Tue, 28 Mar 2006 23:52:11 +0100
Hello Stephen ,


Stephen de Vries wrote:
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! 

Thanks for confirming this (I wonder how many other other Java
developers are aware of this (especially the ones not focused on
security)).

Stephen, do you have any idea of what is the current percentage of 'real
world' Java applications are executed:

    a) with verification

    b) on a secure sandbox

Note that for example I have seen several Java Based Financial
Applications which are executed on the client which either require local
installation (via setup.exe / App.msi) or require that the user grants
that Java application more permissions that the ones allocated to a
normal Sandboxed browser based Java App.

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)

Humm, this is indeed interesting. Ironically, the 1.1 and 2.0 versions
of the CLR will thrown an exception in this case (even in Full Trust).
Since verification is not performed on that .Net Assembly, the CLR might
pick up this information when it is resolving the method's relative
address into the real physical addresses (i.e. during JIT).
Using the same code with an Applet loaded from the filesystem throws
an IllegalAccessError exception as it should.

What do you mean by 'Applet loaded from the filesystem'?

Where? In a Browser?

Best regards

Dinis Cruz
Owasp .Net Project
www.owasp.net


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

<Prev in Thread] Current Thread [Next in Thread>