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

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] [day] [month] [year] [list]

Message-ID: <5e01c29a0603282004t6d174e86s54736c63a666518b@mail.gmail.com>
Date: Wed Mar 29 05:04:37 2006
From: michaelslists at gmail.com (michaelslists@...il.com)
Subject: Re: [Owasp-dotnet] Re: 4 Questions: Latest IE
	vulnerability, Firefox vs IE security, Uservs Admin risk profile,
	and browsers coded in100% Managed Verifiable code

I wonder if you could disable the default security manager with unverified code.

Probably.

Hmm.

-- Michael


On 3/29/06, Jeff Williams <jeff.williams@...ectsecurity.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@...ts.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owasp-dotnet
>