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="">).
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@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
|
