Date: Wed Mar 29 00:17:24 2006
From: eric at eric-swanson.com (Eric Swanson)
Subject: RE: [SC-L] 4 Questions: Latest IE vulnerability,
	Firefox vs IE security, Uservs Admin risk profile,
	and browsers coded in 100% Managed Verifiable code

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@...ts.sourceforge.net
[mailto:owasp-dotnet-admin@...ts.sourceforge.net] On Behalf Of Eric Swanson
Sent: Tuesday, March 28, 2006 3:50 PM
To: 'Dinis Cruz'; jeff.williams@...sp.org
Cc: owasp-leaders@...ts.sourceforge.net; owasp-dotnet@...ts.sourceforge.net;
webappsec@...urityfocus.com; SC-L@...urecoding.org;
full-disclosure@...ts.grok.org.uk; dailydave@...ts.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@...ts.sourceforge.net
[mailto:owasp-dotnet-admin@...ts.sourceforge.net] On Behalf Of Dinis Cruz
Sent: Tuesday, March 28, 2006 2:59 PM
To: jeff.williams@...sp.org
Cc: owasp-leaders@...ts.sourceforge.net; owasp-dotnet@...ts.sourceforge.net;
webappsec@...urityfocus.com; SC-L@...urecoding.org;
full-disclosure@...ts.grok.org.uk; dailydave@...ts.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@...ts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owasp-dotnet
 
  

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20060328/3a65523a/attachment.html

Powered by blists - more mailing lists