full-disclosure - Re: [Owasp-dotnet] Re: 4 Questions: Latest IEvulnerability, 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>] [day] [month] [year] [list]

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