Re: [SC-L] By default, the Verifier is disabled on .Net and Java
Jeff Williams wrote: Two important clarifications for Java (based on my experiments): 1) The verifier IS enabled for the classes that come with the Java platform, such as those in rt.jar. So, for example, if you create a class that tries to set System.security (the private variable that points to the SecurityManager instance), you get a verification exception. (If this was possible, it would allow a complete bypass of the Java sandbox). But with either Type Confusion attacks or with the Security Manager disabled, you can still completely bypass the Java Sandbox, right? 2) The verifier also seems to be enabled for classes running inside Tomcat. I’m not sure about other J2EE containers. This is interesting, do you have any documentation to back this up? Ideally there would be a document somewhere which listed which J2EE containers run with the verifier on by default So I don’t think it’s fair to say that most Java code is running without verification. If all jsp out there is verified then yes 99% is not a correct number, any idea what percentage it could be? But Denis is right. There is a real problem with verification, as demonstrated in the message below. This is a clear violation of the Java VM Spec, yet my messages to the team at Sun developing the new verifier have been ignored. And it’s a real issue, given the number of applications that rely on libraries they didn’t compile. I don’t think a real explanation of how the Sun verifier actually works is too much to ask, given the risk. I agree, and Sun will probably do the same thing that Microsoft is doing at the moment: "Ignore the issue and hope that it goes away" Dinis Cruz Owasp .Net Project www.owasp.net ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
RE: [SC-L] By default, the Verifier is disabled on .Net and Java
I'm psyched about this thread. Rock on guys. For those of you who may need some basics, you might want to read Securing Java (a book I wrote with Ed Felten in 1999...the first edition in 1996 was called Java Security). The book is available completely for free in searchable format at http://www.securingjava.com I bring this up, because many of the terms being properly bandied about in this thread are carefully described there. Types, type confusion, the security model, the role of the verifier, why you can't trust byte code...etc. Happy history. I am feeling rather old. gem www.cigital.com/~gem www.swsec.com This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
RE: [SC-L] By default, the Verifier is disabled on .Net and Java
> $ java -cp . -noverify HelloWorld > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x6d7415fb, > pid=3512, tid=2260 # # Java VM: Java HotSpot(TM) Client VM > (1.5.0_06-b05 mixed mode) # Problematic frame: > # V [jvm.dll+0x615fb] Note that EXCEPTION_ACCESS_VIOLATION is the Windows equivalent of a segmentation violation; this isn't the Verifier complaining, it's the JVM crashing. The fact that editing the .class file allows you to produce one that causes the JVM to crash is pretty strong evidence the verifier was NOT used to validate the file. Tim Hollebeek Research Scientist Teknowledge Corp. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] By default, the Verifier is disabled on .Net and Java
Dinis Cruz wrote:
> Ok, I just did some further tests and I think I can say that Java
> (version 1.5.0_06) has similar verification issues to the ones I
> discovered on the .Net Framework (see links in my previous post).
[...]
> This should prove that the verifier is not enabled by default on java
> files loaded from the local computer.
First, apologies to Dinis and Kevin for the mis-attribution.
I agree, based on the various experiments, it looks like the bytecode
verifier is still not enabled by default for locally loaded class
files. I'm not sure why my randomly modified HelloWorld.class file
behaved differently in the -verify / -noverify cases. If I have more
time, I'll dig into it.
As mentioned, the source code for the jdk is available under the Sun
Community Source License. [1] Unfortunately, this license doesn't
permit redistribution of code to non-licensees, so I'll just describe
what I found when I took a (non-exhaustive) look.
j2se/src/share/bin/java.c:
java {-verify, -verifyremote, -noverify} are aliases for options passed
to the Java Hotspot Virtual Machine. The options are aliased to
-Xverify:all, -Xverify:remote, and -Xverify:none, respectively. These
options, in turn, don't seem to be documented, at least not in the VM
options documentation. [2]
Ah, but they are documented elsewhere. [3] From that document:
8<--
So, why all this verification? When class files are loaded (possibly
over the network or from an untrusted source) into a virtual machine,
there is no way of telling how its byte codes were generated. Basically,
in most cases, you can't trust the source of the Java class files. In
fact, the default verification setting in JRE 1.1 is to only verify
classes loaded from over the network. So, anything installed locally,
via CLASSPATH, is not verified. In JRE 1.1, if you have installed
something locally from a third-party and want to even verify that, too,
you can do that. Or, you can completely disable verification. The three
settings are all options to the java and jre commands:
* -verifyremote - only perform verification process on classes
loaded over network (default)
* -verify - verify everything
* -noverify - verify nothing
In JDK 1.2, the default setting for verification is the same only verify
classes loaded over the network. However, the system classes are
specified from something other than the CLASSPATH environment variable,
and the command line options for verification differ. The system classes
are specified by either the System property sun.boot.class.path or the
command line option -Xbootclasspath:directories and jar files. This is
automatically set for you by the JRE and should never need to be set
manually. If you set it to add something yourself be sure to include the
original defaults, too. With regards to verification, if you wish to
manually control the level of verification, the options to the java
command with the V1.2 JRE are as follows:
* -Xverify:remote - only perform verification process on classes
loaded over network (default)
* -Xverify:all - verify everything
* -Xverify:none - verify nothing
If a verification error is encountered, instead of the JRE reporting a
verification error or throwing an exception, it reports a can't find
error, like: Can't find class MyClass.
8<--
On the other hand, this message from the java-security mailing list
archives [4] (from July 2001) seems to say something else:
8<--
The "system classes" such as those in java.* that are contained in
rt.jar are loaded by the bootstrap class loader built-in to the Java
Virtual Machine. In Jave 2, the next class loader searched for classes
is the extension class loader which looks for classes in the jar files
in the lib/ext directory where the Java Runtime Environment is
installed. The so-called "system class loader" actually loads the
application classes found from the -classpath command line argument or
the CLASSPATH environment variable. Yes, the name "system class loader"
is confusing. It is named that way for historical reasons when both core
system classes as well as application classes were all loaded by the
bootstrap class loader in JDK 1.1.
>
> I thought that, by default, the Java API classes (rt.jar) are the only
ones
> that dont go thru the ByteCode Verifier?
You are correct again. By default, all classes go through the
bytecode verifier except for those loaded by the bootstrap class loader.
You can change this behavior through the use of command line arguments.
This is because all classes except for those loaded by the bootstrap
class loader can by granted fine-grained security permissions. In order
to prevent those classes from cheating and trying to get more
permissions than they have been granted we need to verify them. Classes
loaded by the bootstrap class loader are always granted "AllPermission"
and cannot be granted fewer permissions. These classes are trusted as
part of the
Re: [SC-L] HNS - Biggest X Window security hole since 2000
On Thursday 04 May 2006 12:40, Gadi Evron wrote: > Hmm, I think this was fixed in earlier X versions. Not impossible, but the article clearly indicated that it's in 6.9.0 and 7.0.0, which are the most current in general circulation, I believe. But, some bugs are so important that they deserved to be fixed more than once. It sure wouldn't be the first time that a bug found its way back into a src tree. Cheers, Ken -- KRvW Associates, LLC http://www.KRvW.com pgpSwossK0g5Q.pgp Description: PGP signature ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] HNS - Biggest X Window security hole since 2000
On Thu, 4 May 2006, Kenneth R. van Wyk wrote: > Stories about this (below) X bug and the DHS-sponsored project that found it > have been floating around the net all week. This story caught my eye, > though: > > http://www.net-security.org/secworld.php?id=3994 > > The author claims, "This flaw, caused by something as seemingly harmless as a > missing closing parenthesis, allowed local users to execute code with root > privileges, giving them the ability to overwrite system files or initiate > denial of service attacks." > > So, it sounds like a single byte change in the entire X src tree could fix a > bug that could give an attacker complete control of a system. Lovely... Hmm, I think this was fixed in earlier X versions. Gadi. > > Cheers, > > Ken van Wyk > -- > KRvW Associates, LLC > http://www.KRvW.com > ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
[SC-L] HNS - Biggest X Window security hole since 2000
Stories about this (below) X bug and the DHS-sponsored project that found it have been floating around the net all week. This story caught my eye, though: http://www.net-security.org/secworld.php?id=3994 The author claims, "This flaw, caused by something as seemingly harmless as a missing closing parenthesis, allowed local users to execute code with root privileges, giving them the ability to overwrite system files or initiate denial of service attacks." So, it sounds like a single byte change in the entire X src tree could fix a bug that could give an attacker complete control of a system. Lovely... Cheers, Ken van Wyk -- KRvW Associates, LLC http://www.KRvW.com pgpyqSfoo0SaU.pgp Description: PGP signature ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] By default, the Verifier is disabled on .Net and Java
On 5/4/06, Dinis Cruz <[EMAIL PROTECTED]> wrote: Wall, Kevin wrote: > Also, from the results of your test, it seems to indicate that SOME TYPE > of verification is taking place, but if all you did was change a few > ARBITRARY bytes in the .class file, I don't think that proves the > byte code verifier is being being run in it's entirety. I agree with this analysis and think that the error on David's test was caused by a malformed bytecode instruction > It's entirely possibly that the (new 1.5) default just does some > surface level of byte code verification (e.g., verify that everything > is legal "op codes" / byte code) Well, some level of verification (or bytecode check) must always occur during the conversion from bytecode to native code (but this has nothing to do with type safety) > before HotSpot starts crunching > on it and that this works differently if either the '-verify' or > '-noverify' flags are used. E.g., suppose that '-verify' flag, does > some deeper-level analysis, such as checks to ensure type safety, etc, > whereas the '-noverify' doesn't even validate the byte codes are > legal op codes or that the .class file has a legal format. This might > even make sense because checking for valid file format and valid > Java "op codes" ought to be fairly "cheap" checks compared to the > deeper analysis required for things like type safety. > I am a little bit confused here, isn't Java an open platform and almost Open Source? The source for the j2se sdk is available (i.e. all the classes) and the source for the runtime is available as well, but under a different, special license. If so, shouldn't issues like this be quite well documented? Actually, the verification process is documented here: http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html#88597 -- Michael ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] By default, the Verifier is disabled on .Net and Java
Wall, Kevin wrote: Also, from the results of your test, it seems to indicate that SOME TYPE of verification is taking place, but if all you did was change a few ARBITRARY bytes in the .class file, I don't think that proves the byte code verifier is being being run in it's entirety. I agree with this analysis and think that the error on David's test was caused by a malformed bytecode instruction It's entirely possibly that the (new 1.5) default just does some surface level of byte code verification (e.g., verify that everything is legal "op codes" / byte code) Well, some level of verification (or bytecode check) must always occur during the conversion from bytecode to native code (but this has nothing to do with type safety) before HotSpot starts crunching on it and that this works differently if either the '-verify' or '-noverify' flags are used. E.g., suppose that '-verify' flag, does some deeper-level analysis, such as checks to ensure type safety, etc, whereas the '-noverify' doesn't even validate the byte codes are legal op codes or that the .class file has a legal format. This might even make sense because checking for valid file format and valid Java "op codes" ought to be fairly "cheap" checks compared to the deeper analysis required for things like type safety. I am a little bit confused here, isn't Java an open platform and almost Open Source? If so, shouldn't issues like this be quite well documented? (if not on official documentation, at least on online discussion threads) I have a couple books on java that discuss the verification process, but they are quite old, so It would be good to know the details about the current verification process (as implemented in the latest version) You didn't discuss details of what bits you tweaked, so I'm not quite yet ready to jump up and down for joy and conclude that Sun has now seen the light and has made the 1.5 JVM default to run the byte code through the *complete* byte code verifier. Unfortunately I don't think that Sun has seen the light on this one (and neither has Microsoft) I think more tests are either necessary or someone at Sun who can speak in some official capacity steps up and gives a definitive word one way or another on this. Talking about Sun, where are they? I know that Jeff Williams (Owasp) have tried several times to get a response from them on these issues but has been unsuccessful. Aren't they (Sun) supposed to be much more open and transparent about Java? (at least when compared to Microsoft) I am sure that there must be people from Sun on this list (likewise from Microsoft), and it would be great if they joined this discussion so that we can understand exactly what is going on. Best regards Dinis Cruz Owasp .Net Project www.owasp.net ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] By default, the Verifier is disabled on .Net and Java
David Eisner wrote: Wall, Kevin wrote: 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. Is this (still) true? The -verify and -noverify flag are no longer documented [1], although they are still accepted. Yes it is still true (see my last email on this thread) I did a little experiment (with my default 1.5 VM). I compiled a HelloWorld program, then changed a few byes in the class file with a hex editor. By doing this this (unless you were very lucky in your changes) you will either create an invalid Java bytecode instruction, or will corrupt the .class file So the errors you are getting below don't look like verifier errors (although I can't really explain why the --noverify throws a different error). Can you try to disassemble this corrupted class so see if we can get more details about where the bytecode error is Thanks Dinis Cruz Owasp .Net Project www.owasp.net -8<-- $ java -cp . HelloWorld Exception in thread "main" java.lang.ClassFormatError: Interface name has bad constant pool index 13056 in class file HelloWorld at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) $ java -cp . -verify HelloWorld Exception in thread "main" java.lang.ClassFormatError: Interface name has bad constant pool index 13056 in class file HelloWorld at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) $ java -cp . -noverify HelloWorld # # An unexpected error has been detected by HotSpot Virtual Machine: # # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x6d7415fb, pid=3512, tid=2260 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode) # Problematic frame: # V [jvm.dll+0x615fb] # # An error report file with more information is saved as hs_err_pid3512.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # -8<-- -David [1] http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
