Re: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code
Hi Dinis, On 29 Mar 2006, at 05:52, Dinis Cruz wrote: Thanks for confirming this (I wonder how many other other Java developers are aware of this (especially the ones not focused on security)). Most I've worked with aren't really aware of the security manager, never mind bytecode verification. It is an issue, but the security risk in the real world may be a bit overstated. If I were a maliciously minded attacker that wanted users to execute my evil Java program, I wouldn't need to mess about with the lack of verification, I could just write evil code in perfectly verifiable format and rely on users to execute it. Can anyone come up with attack vectors that exploit lack of verification on downloaded code that couldn't be exploited by other (easier) means? Stephen, do you have any idea of what is the current percentage of 'real world' Java applications are executed: a) with verification b) on a secure sandbox Very few. As Jeff mentioned some Java Application servers ship with a security policy enabled, but the policy doesn't restrict anything (e.g. JBoss), other's show you how to run with a sec policy, but don't apply it by default (e.g. Tomcat). In some cases, with the more complex app servers a sec policy would be of little security benefit because the server needs so much access in order to function properly that the policy could be considered completely open. In some ways I think we're applying double standards here. Just because a virtual machine offers the facility for defining a security policy and verification doesn't mean that it _has_ to use it. There are native executable programs that I trust, so why should a program that runs in a VM be subject to more stringent security controls just because they're available? IMO whether code needs to be sandboxed and controlled by a policy should be decided on a case by case basis rather than a blanket rule. Note that for example I have seen several Java Based Financial Applications which are executed on the client which either require local installation (via setup.exe / App.msi) or require that the user grants that Java application more permissions that the ones allocated to a normal Sandboxed browser based Java App. This is quite common for an app, and granting more permissions is fine as long as those are tightly controlled by the java security policy. Humm, this is indeed interesting. Ironically, the 1.1 and 2.0 versions of the CLR will thrown an exception in this case (even in Full Trust). Since verification is not performed on that .Net Assembly, the CLR might pick up this information when it is resolving the method's relative address into the real physical addresses (i.e. during JIT). Using the same code with an Applet loaded from the filesystem throws an IllegalAccessError exception as it should. What do you mean by 'Applet loaded from the filesystem'? Where? In a Browser? If you load an applet in a browser using a url such as: file:///data/ stuff/launch.html then no verification is performed. But if you access the applet using http/s then it will be verified. cheers, -- 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: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code
Hello Eric (comments inline) Eric Swanson wrote: Because I believe that Microsoft will never be as cooperative with .NET and the developer community as Sun is with Java, is there an opportunity for another company to step up to the plate on Microsoft's behalf? There is definitely an opportunity here. At the moment I see two big players that could move into that space: Novell and IBM. Both have the resources to do it, and the motivation. The main questions are: - Do they want to buy that 'war' with Microsoft? - Do they 'believe' that this a worthwhile project and one that will help their bottom line? - Can they do it in an open and transparent way that attracts a strong community to it? (note that this community will be critical to the project, since I believe that no company in the world has the resources to it by itself) This could also be done by a very dynamic and well funded Open Source project (maybe by several governments or by companies/corporations which decide that they need to be more proactive in the protection of their critical resources and assets) The .NET Framework is completely public, and, although Mono continues to have its workload increased by each Framework release, I think there may be an opportunity for a company or organization to step-in and take the reigns where Microsoft left off. How possible is it to plug-in to the CLR and make extensions to the core? It is very doable. Note that there are already 4 different flavors of the CLR (Microsoft's .Net Framework, Rotor, Mono and DotGnu) See also the Postbuild commercial application (http://www.xenocode.com/Products/Postbuild/) which claims (I have not used it) to create Native x86 executables which allows .NET applications to run anywhere, with or without the Framework. This is something that I always wanted to do since it should (depending how it is done) allow the dramatic reduction of code (and dlls) that needs to be loaded in memory (the ultimate objective would be to create mini-VMs that were completely isolated from the host OS (or only having very specific interfaces / contact points)). Also while I was doing my 'Rooting the CLR' research, since Microsoft does provide the Symbols for core .Net Assemblies, there is a lot that can be done at that level. That said, this work would be greatly simplified if Microsoft released the source code of the entire .Net Framework :) Perhaps a better project for OWASP.NET than security vulnerability detection utilities is a security plug-in to the CLR engine for byte code signature registration and verification? Agree, the problem we have is resources (and lack of funding) Btw, at Owasp .Net we have now much more than just 'Security Vulnerability Detection Utilities' :) Apart from those utilities (namely ANSA and ANBS) we now also have: * Owasp Site Generator : Dynamic website creator to test Web Application Scanners and Web Application Firewalls (and a great tool for developers to learn about security vulnerabilities) * Owasp PenTest Reporter : Tool that aids in the process of documenting, reporting and tracking security vulnerabilities discovered during Penetration Testing engagements * DefApp (Proof of Concept): Web Application Firewall Another project that I would love to do is to work on a plug-in manager for Firefox which would execute all Firefox plug-ins in a managed and verifiable .Net sandbox (maybe built around mono (which was were this idea was suggested to me)) Would this task even be feasible? (Managed code only?) Is it even worth the effort, considering the possibility of further development from Microsoft? I think that it would be worth the effort, the problem is 'who will fund this'. I don't think that this is a project that can be done on the backs of the odd spare times that its main developers would be able to allocate to it. *Personally, I have never attempted to work below the top layers of .NET. It's not that hard :) But, it seems to me that plugging into the core would be a better option than some kind of wrapper sandbox, especially with regard to change control (top layers are likely to change more often and more drastically than lower layers). Absolutely, and remember that ideally this tool would also remove 95% of that 'top layer' since it is not required. I am also not convinced of the robustness of the current implementation of CAS in .Net 1.1 and 2.0. There are too many security demands in too many places. Should it be a task of the OWASP.Java team to work with Sun Mustang? Maybe, but first you need to create that Owasp.Java team :) There are a lot of Java guys at Owasp, but they all are working on separate projects Could there ever be a silver bullet sandbox for all executables, regardless of language? No I don't think so. You will need to look at each different type of executables (mobile code, web apps, desktop apps, windows services, 'real-time apps', etc..) and
Re: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code
On 27 Mar 2006, at 11:02, Jeff Williams wrote: I am not a Java expert, but I think that the Java Verifier is NOT used on Apps that are executed with the Security Manager disabled (which I believe is the default setting) or are loaded from a local disk (see ... applets loaded via the file system are not passed through the byte code verifier in http://java.sun.com/sfaq/) I believe that as of Java 1.2, all Java code except the core libraries must go through the verifier, unless it is specifically disabled (java -noverify). I had the 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. I tested this by compiling 2 classes where one accesses a public member of the other. Then recompiled the other and changed the method access to private. Tested on: Jdk 1.4.2 Mac OS X Jdk 1.5.0 Mac OS X Jdk 1.5.0 Win XP all behave the same. [~/data/dev/applettest/src]java -cp . FullApp Noone can access me!! [~/data/dev/applettest/src]java -cp . -verify FullApp Exception in thread main java.lang.IllegalAccessError: tried to access field MyData.secret from class FullApp at FullApp.main (FullApp.java:23) Using the same code with an Applet loaded from the filesystem throws an IllegalAccessError exception as it should. -- 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
