[SC-L] WSJ.com - Tech Companies Check Software Earlier for Flaws
I saw an interesting Wall Street Journal article today that talks about companies adopting software security practices. Complete story can be found at: http://online.wsj.com/public/article/SB114670277515443282-B59kll7qXrkxOXId1uF0txp8NFs_20070504.html? The article cites a couple of companies that are starting to seriously use some static code analysis tools (Coverity and Fortify) to scan their src trees for security defects. Although it doesn't address much in the way of design-time security activities, it's a good start and it's encouraging to see this sort of coverage in mainstream media. I really liked this quote - "In effect, software makers are now admitting that their previous development process was faulty. While banks and other companies that deal with sensitive customer data began to build security into software development in the late 1990s, Microsoft Corp. and other software makers are only now in the middle of revamping their software-writing processes. " Cheers, Ken van Wyk -- KRvW Associates, LLC http://www.KRvW.com pgpHMXwUbgpNJ.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
An interesting experiment on cracking verifiers was performed about ten years ago by brian bershad at the university of washington. The paradigm used comparative testing on multiple verifiers to find discrepancies. This is covered in securing java as well. Funny how I became interested in software security because of java security. We're coming full circle. gem www.cigital.com/~gem www.swsec.com -Original Message- From: Stephen de Vries [mailto:[EMAIL PROTECTED] Sent: Fri May 05 10:06:36 2006 To: David Eisner Cc: 'Secure Coding Mailing List' Subject:Re: [SC-L] By default, the Verifier is disabled on .Net and Java David Eisner wrote: > > What determines when access to a private member is illegal? Is it, in > fact, the bytecode verifier? Yes, it's done by the fourth pass of the verifier as described here: http://java.sun.com/sfaq/verifier.html#HEADING13 Interestingly, Sun have posted a contest to try and crack the new verifier in Mustang: https://jdk.dev.java.net/CTV/learn.html -- Stephen de Vries Corsaire Ltd E-mail: [EMAIL PROTECTED] Tel:+44 1483 226014 Fax:+44 1483 226068 Web:http://www.corsaire.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 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] HNS - Biggest X Window security hole since 2000
At 11:12 AM -0400 5/4/06, Kenneth R. van Wyk wrote: > Content-Type: multipart/signed; boundary="nextPart1887150.2DlSXmIMA5"; > protocol="application/pgp-signature"; micalg=pgp-sha1 > Content-Transfer-Encoding: 7bit > > 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 Certainly that part is OS-specific. On my VMS machine, X-windows processes do not run as 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... -- Larry Kilgallen ___ 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: > > What determines when access to a private member is illegal? Is it, in > fact, the bytecode verifier? Yes, it's done by the fourth pass of the verifier as described here: http://java.sun.com/sfaq/verifier.html#HEADING13 Interestingly, Sun have posted a contest to try and crack the new verifier in Mustang: https://jdk.dev.java.net/CTV/learn.html -- Stephen de Vries Corsaire Ltd E-mail: [EMAIL PROTECTED] Tel:+44 1483 226014 Fax:+44 1483 226068 Web:http://www.corsaire.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
RE: [SC-L] By default, the Verifier is disabled on .Net and Java
Jim Halfpenny on the Webappsec list has discovered that BEA's JRockit JDK _does_ use verification by default, his complete post quoted below (the test was to access private methods on a class): Hi, BEA JRockit verifies by default and as far as I am aware does not offer a -noverify option. $ java -cp . verifytest2.Main java.lang.IllegalAccessError: getName at verifytest2/Main.()V(Main.java:???) at verifytest2/Main.main([Ljava/lang/String;)V(Main.java:12) Tested with JRockit 1.4.2_08. Regards, Jim Halfpenny ___ 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
I noticed quite a lot of Linux distros have already patched this or are as I write. Do not know if X Org has yet but remember a post by Securnia about this a day or so. Regards, George Greenarrow1 InNetInvestigations-Forensic - Original Message - From: "Kenneth R. van Wyk" <[EMAIL PROTECTED]> To: "Gadi Evron" <[EMAIL PROTECTED]> Cc: "Secure Coding" Sent: Thursday, May 04, 2006 10:37 AM Subject: Re: [SC-L] HNS - Biggest X Window security hole since 2000 > ___ > 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
Re: [Owasp-dotnet] Re: [SC-L] By default, the Verifier is disabled on .Net and Java
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" I don't think so; they've got their Crack the Verifier initiative; and honestly, I don't think it's a big deal of verification isn't on by default on the desktop vm; when you double-click a jar it runs in a new vm, not with a current app you might also be running. As long as j2ee containers (tomcat as Jeff says, websphere as I've heard, and BEA WebLogic as someone else suggested) all run with verification I don't think it's a big deal [but interesting to note], is it? FWIW I've seen this "issue" come up many many times in the java forums and it's never taken this track. It's interesting to see it develop this way ... -- 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
Tim Hollebeek wrote: > 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. > Right. What follows is a summary of what we know so far, and what I think is going on. The details get a bit gory at the end, but you can skim it. I ran the corrupted .class file three ways, and obtained these results: 1) (no switch): ClassFormatError exception 2) -verify: ClassFormatError exception 3) -noverify: JVM crash (EXCEPTION_ACCESS_VIOLATION) I thought (incorrectly) that this might indicate that providing no switch was equivalent to -verify. In fact, it now appears that providing no switch is equivalent to -verifyremote (see my previous message). If I do the same experiment again, I see that, yes, "java -verify" and "java -verifyremote" produce the same result, and "java -noverify" crashes the JVM. This suggests to me that the locally loaded HelloWorld.class file is considered "remote" code. On the other hand, Michael's and Dinis's experiments show that (using Michael's example, after recompiling Foo.java once k is made a private member): 1) (no switch / -verifyremote ): illegal access to private member ALLOWED 2) -verify (i.e. -Xverify:all): illegal access to private member CAUGHT 3) -noverify( i.e. -Xverify:none): illegal access to private member ALLOWED So in this case, cases 1 and 3 are the same (with my mangled .class file experiment, cases 1 and 2 are the same). This suggests that the Foo.class file is being treated as "local" code. How are we to understand this? The short answer is that the meaning of "remote" depends on what type of verification Sun's hotspot VM is doing. With the help of Gary's book [1][2] (thanks!) we note that the Verifier, in verifying classes, performs two kinds of checks: "verification time" checks (steps 1-3 of page [2]) on the class file and its bytecodes, and "runtime" checks, checks that can't be done at verification time because "aspects of Java's type system cannot be statically checked." This includes "check[ing] the executing method for access privilege." This is step 4. on page [2] of Gary's book). We see that my experiment involves static, verification-time checks. Michael and Divis's experiments, on the other hand, involve runtime checks. It appears that the VM is treating .class files loaded through the CLASSPATH as "remote" for the purpose of verification-time (i.e. static) checks, but treating them as "local" for the purpose of run-time access checking verification. Just to verify this, here is another experiment, again with the corrupt class file (actually, this is the HelloWorld.class from my last email, so it's a slightly different ClassFormatError). First, I run with java -verifyremote and get the ClassFormatError. This means the VM thinks ./HelloWorld.class is remote. Next, I use the -Xbootclasspath/a switch to add the current directory to the bootclasspath. This should cause the VM to treat ./HelloWorld.class as it does the system classes in rt.jar, etc, i.e., "local." And, yes, now, I get the JVM crash, even with -verifyremote: ---8<-- $ java -verifyremote HelloWorld Exception in thread "main" java.lang.ClassFormatError: Invalid method Code length 858993413 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 -Xbootclasspath/a:. -verifyremote HelloWorld # # An unexpected error has been detected by HotSpot Virtual Machine: # # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x6d72dacf, pid=5168, tid=3576 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode) # Problematic frame: # V [jvm.dll+0x4dacf] # # An error report file with more information is saved as hs_err_pid5168.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # ---8<-- Summary of what I think happens, more or less, with the 1.5 JRE. 1. DEFINITIONS a) "Bootstrap Class": any class that was loaded by the "Primordial Class Loader." [3] (aka "bootstrap class loader.") Classes in the bootstrap classpath are one example (like classes in rt.jar). b) "O
