Full Disclosure mailing list archives
RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code
From: "Eric Swanson" <eric () eric-swanson com>
Date: Tue, 28 Mar 2006 16:05:30 -0700
One further question: Can we ever really advise developers on how to develop secure code when the foundations they are developing on top of are inherently insecure? If the answer is ultimately no (without re-writing the end-client OS or execution framework), we must then consider the question, how can we make a good business case for developing secure solutions when, ultimately, the secure solution can be compromised? Complete security is never the ultimate destination, but rather mitigating risk through any acceptable means. --Eric S. _____ From: owasp-dotnet-admin () lists sourceforge net [mailto:owasp-dotnet-admin () lists sourceforge net] On Behalf Of Eric Swanson Sent: Tuesday, March 28, 2006 3:50 PM To: 'Dinis Cruz'; jeff.williams () owasp org Cc: owasp-leaders () lists sourceforge net; owasp-dotnet () lists sourceforge net; webappsec () securityfocus com; SC-L () securecoding org; full-disclosure () lists grok org uk; dailydave () lists immunitysec com Subject: SPAM-LOW: 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
What we need now is focus, energy and commitment to create a business
environment where it is possible (and profitable) the creation, deployment and maintenance of applications executed in secure sandboxes. Traditionally, the quickest answer to a need like this is terrorism of some kind to get people to "wake up" to imminent threats. But, since we're in the business of only helping and not hurting. How do we motivate management decisions to support developing more secure solutions? It's the same question as motivating better problem definitions, code requirements gathering, documentation, refactoring, performance optimizations, etc. Time and budget. The answer is to have an affordable, flexible development process and tools that support these motivations. In .NET, code reflection and in-line XML comments coupled with formatting tools like "NDoc" made professional code documentation an instant option available to every .NET developer, even those on a shoe-string budget. The answer from OWASP might be to re-evaluate development processes and develop both sandboxes for clients as well as security patterns, components, wizards, and utilities for developers. We could re-write development processes like the hot topics "Agile Development" and "Extreme Programming" to include the SSDL, "Secure Software Development Lifecycle". Perhaps we should be making a better business case for the SSDL, like the 2nd Edition of Code Complete's "Utterly Compelling and Foolproof Argument for Doing Prerequisites Before Construction" (Print ISBN: 0-7356-1967-0). Our guides and vulnerability detection utilities just scratch the surface. The utilities in particular do not directly address our concerns for motivating the community, except by opening the eyes of the developers who actually use them and giving them something fun to play with. Given the many options that lay ahead of the group, my opinion would be to work on better incorporating the SSDL into popular development processes and making a clear-cut business case (with statistics) for its inclusion. To motivate participation, we continue to develop the utilities, patterns, components, and wizards for developers (both before and after the development release cycle). Perhaps we take the online guides, checklists, and utilities and begin to formulate what SSDL looks like through OWASP's eyes. *Dinis / Jeff - Please trim down the reply list if we should not be including all of these lists on this thread. Eric Swanson _____ From: owasp-dotnet-admin () lists sourceforge net [mailto:owasp-dotnet-admin () lists sourceforge net] On Behalf Of Dinis Cruz Sent: Tuesday, March 28, 2006 2:59 PM To: jeff.williams () owasp org Cc: owasp-leaders () lists sourceforge net; owasp-dotnet () lists sourceforge net; webappsec () securityfocus com; SC-L () securecoding org; full-disclosure () lists grok org uk; dailydave () lists immunitysec com; 'Wall, Kevin' Subject: 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 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) I think your answer shows clearly that the Java camp should also be participating in these discussions. In fact I also would like to ask "Where are the Java Guys/Girls?" I have been talking for two years now on the dangers of .Net Full Trust code, and have not seem much discussion on the dangers of 'Security Manager disabled Java code' (since the problems are exactly the same). Malicious Java code, executed with the Security Manager Disabled in a user's desktop or in a server, is as dangerous as Full Trust .Net code. This comes back to that great concept called 'Faith-based' Security (see Gunnar Peterson's post http://1raindrop.typepad.com/1_raindrop/2005/11/net_and_java_fa.html ), which is when people are told so many times that something is secure, that that they believe that it MUST be secure. Some examples: - "Java is more secure than .Net" (meaningless discussion unless we also talk about the Sandboxes the code is running under) - "IIS 6.0 is more secure that IIS 5.0" (today, is a fully patched IIS 5 (with urlscan ISAPI filter) more 'secure' than a IIS 6.0? Most people will automatically say yes, but if you do a Risk analysis to both, you will see that the risk is just about the same: both ARE able to sustain malicious 'Internet based' anonymous attacks (since there are no reported unpatched vulnerabilities and zero-days exploits), and both are NOT ABLE to sustain malicious Full Trust Asp.Net code executed from within one of its worker processes - "Open Source apps are more secure than Closed Source apps" (again, not an automatic truism) - "Linux and Mac are more secure than Windows" (that depends on how it is configured, deployed, maintained, and more importantly, how it is used). - "If only we could get the developers to write 'secure code' there would be no more vulnerabilities" (this is the best one, a good example of 'Faith Based Security' with 'Blame the guy in the trenches that doesn't complain (i.e. the developers)' (note that I don't think that developers have SOLE (or even MAIN) responsibility in the process that leads to the creation of insecure applications)) -"I.E. is more insecure than Firefox" (apart from the unmanaged code discussion we had earlier, I just say this: Firefox plug-ins. The best way to Own millions of computers is to write a popular Firefox plug-in (which to my understanding runs directly on Firefox's process space and not contained in any type of Sandbox)) I hope the Java camp will also join this discussion on how to create 'real world' applications which can be executed in safe Sandboxes. Ultimately my main frustration is that both .Net and Java have built into their framework technological solutions which COULD deliver such environments (CAS and Security Manager). The problem is that they were designed to handle a very specific type of code (the so called 'Mobile code') for a specific set of applications (browser based components and mobile devices), not the complicated,massively interconnected, feature-rich apps that we have today. What we need now is focus, energy and commitment to create a business environment where it is possible (and profitable) the creation, deployment and maintenance of applications executed in secure sandboxes. Dinis Cruz Owasp .Net Project www.owasp.net 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). Note that Mustang will have a new, faster, better? verifier and that Sun has made the new design and implementation available to the community with a challenge to find security flaws in this important piece of their security architecture. https://jdk.dev.java.net/CTV/challenge.html. Kudos to Sun for engaging with the community this way. --Jeff ------------------------------------------------------------------------- This List Sponsored by: SpiDynamics ALERT: "How A Hacker Launches A Web Application Attack!" Step-by-Step - SPI Dynamics White Paper Learn how to defend against Web Application Attacks with real-world examples of recent hacking methods such as: SQL Injection, Cross Site Scripting and Parameter Manipulation https://download.spidynamics.com/1/ad/web.asp?Campaign_ID=701300000003gRl -------------------------------------------------------------------------- ----------------------------------------- The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message may be an attorney-client communication and/or work product and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642> &kid=110944&bid=241720&dat=121642 _______________________________________________ Owasp-dotnet mailing list Owasp-dotnet () lists sourceforge net https://lists.sourceforge.net/lists/listinfo/owasp-dotnet
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Buffer OverFlow in ILASM and ILDASM, (continued)
- Buffer OverFlow in ILASM and ILDASM Dinis Cruz (Mar 26)
- 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 Dinis Cruz (Mar 26)
- 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 Jeff Williams (Mar 26)
- Re: 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 KF (lists) (Mar 26)
- 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 Stephen de Vries (Mar 27)
- 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 Dinis Cruz (Mar 28)
- 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 Eric Swanson (Mar 27)
- 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 Dinis Cruz (Mar 28)
- 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 Jeff Williams (Mar 26)
- 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 Dinis Cruz (Mar 28)
- 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 Eric Swanson (Mar 28)
- RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code Eric Swanson (Mar 28)
- 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 Gunnar Peterson (Mar 29)