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-dotnet] Re: 4 Questions: Latest IE vulnerab

Subject: [Full-disclosure] Re: [Owasp-dotnet] Re: 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in100% Managed Verifiable code
Date: Wed, 29 Mar 2006 15:04:28 +1100
I wonder if you could disable the default security manager with unverified code.

Probably.

Hmm.

-- Michael


On 3/29/06, Jeff Williams <jeff.williams@aspectsecurity.com> wrote:
Jeff, as you can see by Stephen de Vries's response on this thread,
you are wrong in your assumption that most Java code (since 1.2)
must go through the Verifier (this is what I was sure it was
happening since I remembered reading that most Java code executed
in real-world applications is not verified)

Wow.  I ran some tests too, and Stephen is absolutely right.  It appears
that Sun quietly turned off verification by default for bytecode loaded from
the local disk (not applets).  They've apparently
(http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4030988), acknowledged
that it is a bug, and said that it will not be fixed.  The change had
something to do with compatibility with old bytecode.  More details
(http://www.cafeaulait.org/reports/accessviolations.html)

This is a clear violation of the JVM Spec. And (regardless of protestation
to the contrary) it IS a big security problem.  Just because bytecode is
loaded from the local disk does not mean it's trustworthy.  Every
application uses lots of libraries that developers download from the
Internet (as compiled jar files) and loaded from the local disk.  Unless you
run with "java -verify" that code won't get verified.

I'm sure that the percentage of applications that are running with both
verification and sandbox is terrifyingly small.  Probably only applets and
maybe Java Web Start applications.  As I mentioned before some of the J2EE
servers are now enabling a sandbox, but their security policies are
generally wide open.

I think there are two relatively easy things we can do here. First, let's
find out what plans Sun has for the new verifier -- we should strongly
encourage them to turn it on by default.  Second, we can work on ways to
encourage people to use sandboxes -- tools, articles, and awareness.

--Jeff





-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Owasp-dotnet mailing list
Owasp-dotnet@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owasp-dotnet


_______________________________________________
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>