Message-ID: <4429B1A0.5040800@ddplus.net>
Date: Wed Mar 29 00:12:21 2006
From: dinis at ddplus.net (Dinis Cruz)
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&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/96f3dff4/attachment.html

Powered by blists - more mailing lists