Message-ID: <caeffbf4f0f447d99bada542f01cf485@ddplus.net>
Date: Wed Nov  2 09:40:16 2005
From: dinis at ddplus.net (Dinis Cruz)
Subject: 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

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

Powered by blists - more mailing lists