[<prev] [next>] [day] [month] [year] [list]
Message-ID: <5e01c29a0603282023g6288fb0g84570405fae405f6@mail.gmail.com>
Date: Wed Mar 29 05:23:47 2006
From: michaelslists at gmail.com (michaelslists@...il.com)
Subject: Re: [Owasp-dotnet] Re: 4 Questions: Latest
IEvulnerability, Firefox vs IE security, Uservs Admin risk profile,
and browsers coded in100% Managed Verifiable code
I just tried a few ways and couldn't figure anything out;
It doesn't seem like you can modify a java.lang Class from outside the
package (even unverified) and I also couldn't get my class _inside_
java.lang.
Maybe BCEL can get further ... or maybe I missed something.
-- Michael
On 3/29/06, michaelslists@...il.com <michaelslists@...il.com> wrote:
> 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
Powered by blists - more mailing lists