RE: What are the 'Real World' security advantages of the.Net Framework and the JVM?

["Edward Ray" <support () mmicman com>]

Interesting, I was just about to post a question to this newsgroup on "What
is .NET Security?"
 
I just volunteered at the SANS Los Angeles conference to take a six day
course in ".NET Security"
 
My analysis on .NET based on that experience is that .NET is nothing more
than middleware.  It provides little or no real security features.  It is
sold as a buffer between the dumb (evil) codes and the nice (but insecure)
Windows OS.  In goes the evil code, out comes nice code that the Windows OS
will devour hungrily.
 
Here is a thought, why not write a secure OS and teach codes to write better
code with minimal opportunity to exploit stack/heap overflows?  Isn't that
what CANVAS, metasploit, etc are and aide to help in this regard?
 
.NET Security is an oxymoron, IMHO.  If anyone has a different take on this
topic that is has not partaken of the Microsoft Kool-Aid on this subject, I
would appreciate enlightenment.

 
Edward W. Ray
CISSP, MCSE 2003+Security, P.E. GCIA Gold, GCIH GOLD
NetSec Design & Consulting 
http://www.netsecdesign.com


________________________________

From: Dinis Cruz [mailto:dinis () ddplus net] 
Sent: Wednesday, November 02, 2005 1:49 AM
To: dailydave () lists immunitysec com
Subject: [Dailydave] What are the 'Real World' security advantages of
the.Net Framework and the JVM?


What are the 'Real World' security advantages of the .Net Framework and the
JVM?

The reason I am asking this question is because the way the .Net Framework
and the JVM are used in the real world, I don't see any major advantages
between them and C++, ASP Classic, PHP, ...(put your favorite
language/development platform here)..., etc...

The bottom line, is that in the 'Real Word', most .Net Applications execute
with Full Trust and most Java based applications run with the Security
Manager disabled. This means that the protections and security advantages
provided by the Virtual Machine's Sandboxes (CLR and JVM) are close to
useless since malicious code executed in those process can easily bypassed
it.

The reality is that 'Real World' .Net and Java applications are insecure by
design, insecure by default and insecure in deployment, because their entire
security model is based on the fact that no malicious code will be executed
in its environment.

Let's look at different types of applications, do a quick threat model and
try to find the security advantages provided by .Net or JVM:

Case Study 1: Web application
    
1.1 Attack vector #1: Anonymous or user based attacks (launched from the
Internet).

1.1.1 Vulnerabilities exploited: Input Validation, Authorization failures or
pour session management

1.1.2 Comment: A developer team that doesn't understand security (or doesn't
have a solid Software Development Life cycle) can create these
vulnerabilities in any language (C++, C#, Java, PHP, etc...) which allow the
total compromize of the application. Note that even if there is a solid SDL
and the developer team does understand security, vulnerabilities (or
potential exploit vector) will be created because it impossible to create
100% bug-free complex software systems.

1.1.3 Impact of .Net or Java in the rating and quantity of vulnerabilities:
> From my experience, VERY LITTLE. So far .Net and Java websites are as
vulnerable (if not more since they tend to me more complex) as websites
developed in other languages/architectures

1.2 Attack vector #2: Malicious code is uploaded and executed in one of the
website's pages (or components)

1.2.1 Comment: This is where the CLR and JVM should come into action and say
"All code executed from this website ONLY has access to these permissions
and is not able to access any more resources than the ones allocated!", the
problem is that the way the .Net Framework assemblies (and Java code) are
used in the real world, both CLR and JVM can be easily bypassed whereby the
malicious code is only limited by the restrictions (if any) imposed by the
Operating System to the account used to execute that code

1.2.2 Impact of .Net or Java in the rating and quantity of vulnerabilities:
NONE. If, for example, the .Net code was executed in a solid Partial Trust
environment, then YES, there would a substantial positive impact in the
rating and quantity of vulnerabilities. But with Full Trust, there is no
difference between a .Net assembly and an unmanaged DLL. The perfect case
study is IIS 6.0 which is as insecure as IIS 5.0 when handling malicious
code executed from a co-hosted website (from a security point of view
'Application Isolation' doesn't exist in IIS 6.0 since IIS 6.0 is not able
to sustain an malicious attack from the inside)

Case Study 2: Fat Client working with a Server based
Website/WebService/Remoting service

2.1.1 Attack vector #1: Malicious user has local access to the Application
(.Net or Java) and uses it to 'attack' the server

2.1.2 Comment: This is an area where most fat applications fail because the
original developers never expected the server components to be attacked from
their own client application (which they spend thousand of hours programming
security 'measures' like 'menu-items, buttons, textboxes which are only
enabled for administrators'. The problem is most client applications run in
the context of the user, and the user (no mater how low-privileged it is)
will have TOTAL access and control over that process. Which means that there
is nothing stopping the malicious user from changing the code of the client
application so that it behaves in a way the original developers never
expected (i have even found applications that construct SQL server queries
on the client components)

2.1.3 Impact of .Net or Java in the rating and quantity of vulnerabilities:
NEGATIVE (i.e. they make this much more dangerous). Where in pure unmanaged
applications you have to work with low level function hooks (ala Detours) in
.Net you can use reflection and have full access to the entire application
object model in a very user friendly way (obfuscation will make this a
little harder and less user friendly, but since the .Net's BCL (Base Class
Library) is not obfuscated, it is still very easy to see what is going on)

As you can see in both presented scenarios the .Net Framework or JVM have
little impact on the security of the final applications (by security I mean
capability to sustain an attack). Or course that there are many more
scenarios which we could discuss here, and in some the CLR/JVM security
advantages might have some significance. But the bottom line is that after
10 years of Java and 5 of .Net the current application landscape is not more
secure (we still have 100s of input validations issues (Buffer overflows in
C++, SQL Injection in c#), and logic-errors and authorization flaws are
still very un-explored attack vectors)

What frustrates me (as somebody who is asked to protect systems and create
secure runtime environments) is that both .Net and Java have a (sort of)
workable solution in their architectures (I talking about Sandboxing). The
problem is that due to a massive lack of foresight by Microsoft and the Java
community, the amount of effort and focus that is currently placed in
creating real-world applications that are designed to execute in these
secure runtime environments in minimal.

We are still talking about the basics! Microsoft is yet still to publicly
acknowledge that is a MASSIVE PROBLEM the fact that 99% of .Net applications
are designed for, and executed in Full Trust!

It now two years that I have been in direct conversation with dozens of
Microsoft contacts (from the Microsoft Security Response Center to a product
manager of the ASP.NET team), and the answer is always the same: "Dinis,
what you are talking about occurs by design and is not a vulnerability!" and
"We know that Full Trust is a problem and we are trying to communicate that
to your clients".

According to the 'current' definition of 'what is a security vulnerability'
the following 'features' were not vulnerabilities:

    - Outlook allowed emails direct access to the emails objects
('mail-merge' feature)
    - Internet explorer allowed almost unlimited access to ActiveX
components (or Browser Help Objects) 
    - Windows 2000 and 2003 Web edition have no Firewall and can be 'safely'
connected to the Internet (RPC is such a 'friendly protocol')
    - Everything was turned on by default (namely IIS)
    - Windows messages from one window to another (WM_TIMER anyone?)
    - Windows 95 lack of internal isolation (i.e. there is no kernel
protection in windows 95 and any process can 'patch' the entire OS)

The above features only became 'vulnerabilities' and worth Microsoft
Security team focus once they started to be exploited. So until the 'Full
Trust' issue becomes an attack vector, it will not be a 'vulnerability'
(just remember that you can't 'patch' an application designed to execute in
Full Trust). 

I was hoping that with .Net 2.0 Microsoft would take the opportunity to
change its tune and make some radical changes in its attitude to security
and the "Full Trust .Net world" that they are creating. But I was very
disappointed to see that they haven't.

But hey, the good news is that there is no RISK, since RISK = Vulnerability
* Impact * Probability (probability = number of occurrences * time).

Although the Vulnerability and Impact are very high, the probability of an
exploitation actually occurring is very low (i.e. the number of exploits
targeting Full Trust .Net apps is still very low)

Just look at the number of ISPs that execute their client's websites with
Full Trust and try to find examples of massive exploitation to see that the
risk (so far) is quite low

But, the best example of this 'No Risk' reality is given to us by ORACLE
with its reaction to David's Litchfield open letter and to public disclosure
of the existence of dozens of unpatched Oracle vulnerabilities. 

Basically by not reacting and not addressing the issues properly, what
ORACLE is saying is "Although you (David) and others are able to easily
exploit our 'unbreakable' databases, in the 'real world' the number of
people actually doing it maliciously is very low. 
So, since our clients are not losing considerable amounts of money with
these vulnerabilities, and you (David & Co) will not maliciously exploit
them, nothing will change until: 
  A) there are enough attacks which cause considerable amounts of financial
losses or 
  B) the people (and corporations and governments) affected start to REALLY
complain and apply serious pressure. 
Meanwhile, in the 'Real World', Oracle databases will continue to be massive
insecure, we (oracle) will continue to say that they are 'unbreakable', the
media will NOT challenge that claim, and everybody will be happy (except for
the people directly affected by the exploitation of Oracle databases)"

Oracle's current attitude to security is so bad, that they even make
Microsoft looks good :)

But Microsoft doesn't get 'Application Security'. Unless something is
wormable or exploitable from the Internet, from the current Microsoft's
point of view it is not a vulnerability (note that Microsoft DOES get
'Infrastructure Security' (i.e. networked based attacks, buffer overflows,
etc...)). 

But then again, why should them? Most likely Microsoft's clients are putting
no pressure to address this issue! Everybody is still too focused on:
"features, easy of use, rapid development, features, easy of use, rapid
development, features, easy of use, rapid development..... oh ... and it has
to be secure..... features, easy of use, rapid development, features, easy
of use, rapid development, features, easy of use, rapid development  ... did
I mention security?.....   features, easy of use, rapid development,
features, easy of use, rapid development...." 

So the main factors that affect the security today, is 
  A) how much money is being lost by insecurity and 
  B) how much 'real focus' (versus marketing efforts) and senior support
there is in creating secure products/applications.

This has more impact on the final product's security (whether it is an
application or website) than the choice of technologies used.

Which takes me to my original question: "What are the 'Real World' security
advantages of the .Net Framework and Java?"

To which I will give two answers: 

1) "Theoretically both should have a major impact. If and only if, .Net and
Java applications are designed (and deployed) in solid Sandboxed
environments where a bug is very hard to be maliciously exploited and the
benefits of having a managed environment (and type safe languages) are
realized"

2) "No Impact, if (as it occurs in the real world today) the .Net assemblies
are executed with Full Trust and the JVM without the Security Manager".

There are two main pillars that seem to sustain most (if not) all security
architectures:

1) No Vulnerabilities can exist (since one single vulnerability will allow
Full Compromize)
2) No malicious code can be executed from the inside (since it will be able
to take full control over the application or server because internal code is
not executed inside a sandbox)

Both are unrealistic, and impossible to guarantee. Unless these two
paradigms change, there will be no major improvements the security of
applications.

And please don't turn this around into a discussion between Open
Source/Microsoft, since I also know very high profile example of Open Source
projects who are happy to sit on non-public vulnerabilities (reported to
them) and do nothing about it unless they start to be publicly exploited (or
publicly disclosed)

In my view most Open Source projects are caught in Microsoft's trap of
evaluating products based on the number of vulnerabilities that exist (read:
"have been publicly acknowledged"). This is a stupid way to evaluate a
product and has a very damaging side effect which is that makes everybody
'allergic to vulnerabilities' (i.e. the hard part is to convince somebody
that 'something' is a 'vulnerability'). And anything mid-term, i.e. NOT
being exploited today (like the Full Trust issue that I have been talking
about for two years now) WILL NOT be considered to be a vulnerability and
will NOT be  addressed in the way it should.

Finally a quick disclaimer. I don't claim to be an Java expert but I will
claim that I know a couple of things about the .Net framework and I would
recommend anybody that relies on the security of the CLR to see the research
that I did for my Owasp Washington presentation entitled 'Rooting the CLR'.
I did this research so that when I say '...the fundamental design problem
with the .Net framework is that the entire Framework (i.e. all dlls) are
loaded into the process that will execute the Full trust Code. Which means
that there is nothing stopping a malicious Full Trust .Net assembly to
'patch' the CLR itself...' people actually see what I mean. My demos were:
    - CLR patch that allowed calls to private methods to succeed
    - CLR patch that allowed corrupted Strong Named assemblies to be
executed (i.e. ILDASM a signed .Net assembly, change it, ILASM it back into
.exe format, and execute it without any exception been thrown)
    - Load core .Net framework dlls that come from directories under my
control (for example c:\fusion.dll)
    - MSIL Patch on all Deny and Demand methods so that they always return
without any exception being thrown, which disables most CAS protections in
the running assembly (the only caveat with this demo is that the 'MSIL
patch' must be applied before those methods are JITED)

At the Owasp conference I spoke with several colleagues from the Java camp
which confirmed to me that you can do similar stuff in the JVM and that in
the 'Real World', the JVM sandbox is not widely used. Please feel free to
correct my Java analogies to .Net   because I'm sure I got some of them
wrong.

As a final note, please remember that I am talking about the SECURITY of
applications, I am not talking about the quality and effectiveness of these
programming languages, platforms or architectures. There are enormous
advantages in witting applications in .Net 1.1 (and now 2.0) when compared
to VB 6.0 or ASP Classic. Both version (1.1 and 2.0) have an amazing range
of features and allow the rapid development of very powerfully applications
(same for Java). My issue is with the 'resilience to attacks' and 'ability
to sustain an attack from an internal user', to which both .Net and Java
fail in the real world. 

Hope this makes sense and I'm looking forward to your comments on the 'Real
World' security advantages of the .Net Framework and Java

Best regards

Dinis Cruz
.Net Security Consulant
Owasp .Net Project Leader
www.owasp.org