Vista and the Type Safe missed oportunity (was Re: New security website: darkreading )

[dinis at ddplus.net (Dinis Cruz)]

Gary,

The Vista/.Net article 
(http://darkreading.com/document.asp?doc_id=93335&WT.svl=column1_1) is 
an excellent article which I agree 100%. Given the fact that Vista will 
crash and burn (with regards to security), this could prove to be a very 
serious mistake by Microsoft.

What makes this worse is that even in Vista, the migration to to managed 
and verifiable environments will not begin.

If vista was released with an effort to make all .Net apps run in 
partial trust (and real focus in making that work), then at least a 
major paradigm-change would occurred and we would be on the right track. 
But unfortunately, that will not happen, which means a couple more years 
wasted.

I agree with the 10 year opportunity window, and since Microsoft has 
chosen to blow they opportunity in this decade, maybe a new contender 
will appear,  put enough resources and effort behind it, and create an 
operating system on a type-safe platform (Open Source community, are you 
listening?).

A couple comment on your article:

/"... .NET has a built-in security model just like Java. //.NET is type 
safe just as Java is type safe. ..."/
  
This is only correct when .Net is executed under Partial Trust and Java 
with the Security Manager enabled.

In Full Trust .Net or Java with Security Manager disabled, the VM 
verifier is disabled and the built-in security mode is just about useless.

The main security advantage that the current .Net and Java environments 
have, is that they are not as vulnerable to buffer overflows as C/C++

/"... At the moment, it's hard to know what's going to be so great about 
Vista..."/

So far one of the security 'benefits' that Vista claims to bring is the 
ability to run applications as non admin and to add some protection to 
user land processes (see 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/AccProtVista.asp). 


The problem is that these protections might be very effective in 
protecting the computer from Rootkits, but are not effective when the 
attacker is after the user's assets (which are located on user-land)

/"... The problem, it turns out, is that the .NET builders did not give 
much thought to providing many of the essential basic building blocks 
that operating systems construction crews need for their work. ..."/

I also think that the current CLR is not designed for that task. To pull 
this off you will need different types of CLR, and probably even 
different type-safe environments.

Another big problem was the lack of mass adoption of the CLI Standard 
caused probably because Microsoft never released the source code of the 
.Net Framework and decided to provide a 'Proof of Concept' thing called 
Rotor.

The path to a type-safe world is one that Microsoft cannot walk alone. 
It will require a massive amount of effort by all parts of the software 
food-chain. The momentum and energy required for such task will be very 
hard (if not impossible) to generate on top of closed (proprietary) or 
partially-open architectures.

/"... In a type-safe language like Java or .NET, there are more 
guarantees about what is what...."
/
If the verifier is enabled...

/"...//In case of monkey business, the Verifier is around to make sure 
that byte code and CLR plays by the rules of type safety..."/

This statement is not entirely correct because 99% of the .Net and Java 
code that is currently deployed is executed on an environment where the 
VM verifier is disabled,  .

What you can say is that, in principle and if all went well, the code 
produced by (for example) Visual Studio C# and VB compilers is Type Safe.

The real security implications of not running .Net code under a verifier 
are still be to researched and the more I look at it the more I think 
that there will be problems ahead.

/"... Type safety is a necessary, but not sufficient, foundation for 
modern security models like the .NET security model..."/

Absolutely, but unfortunately we don't even have that today (type safety 
code execution)

/"....In fact, if we step into the way-back machine, a number of the 
spectacular Java security holes that I helped to find 10 years ago 
involved screwing around with types using the "type confusion toolkit.".."

/And I put money that similar issues exist on the .Net Framework. In 
fact some of my .Net Type Safety research was done by studying the Java 
research on the subject and applying the exploits to the .Net's CLR :)

/"... the next huge opportunity to cause widespread adoption of 
type-safe systems comes around...."
/
Before this happens, the paradigm into Partially Trusted Applications / 
Sandboxes needs to be made.

/"...Microsoft? How about building the next operating system on a 
type-safe platform?..."

/Good luck, for me I have given up on Microsoft on this issue. I don't 
expect nothing major to occur until Vista's failure to deliver a secure 
and trustworthy computing environment is obvious to everybody.

The ones that I wish were listening are Novel and the Mono project. The 
path to a type-safe platform could start there.

Dinis Cruz
Owasp .Net Project
www.owasp.net

Gary McGraw wrote:
> Hi all,
>
> Some of you may have read some of the monthly [in]security columns I
> wrote for IT Architect over the last couple of years (a collection lives
> here http://www.cigital.com/resources/gem/).  CMP killed IT Architect
> (taking out the [in]security column with it) in March.  Fortunately,
> they created a new security website called darkreading that debuts
> today.  I have a column there now.
>
> The first iteration discusses Vista and .NET.  Type safety anyone?
> http://darkreading.com/document.asp?doc_id=93335&WT.svl=column1_1
>
> gem
> www.cigital.com
> www.swswc.com
>
>
> ----------------------------------------------------------------------------
> 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 at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060502/a759ab9a/attachment.html