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]

Re: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE

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
Date: Mon, 27 Mar 2006 20:50:10 +0700

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@corsaire.com Tel: +44 1483 226014 Fax: +44 1483 226068 Web: http://www.corsaire.com






------------------------------------------------------------------------- This List Sponsored by: SpiDynamics

ALERT: "How A Hacker Launches A Web Application Attack!" Step-by-Step - SPI Dynamics White Paper
Learn how to defend against Web Application Attacks with real-world examples of recent hacking methods such as: SQL Injection, Cross Site Scripting and Parameter Manipulation


https://download.spidynamics.com/1/ad/web.asp?Campaign_ID=701300000003gRl
--------------------------------------------------------------------------

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