Secure Coding mailing list archives
[Owasp-dotnet] RE: 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code
From: dinis at ddplus.net (Dinis Cruz)
Date: Mon, 27 Mar 2006 02:34:57 +0100
Hi Kevin
Indeed this is somewhat surprising that there is no byte-code verification in place, especially for strong typing, since when you think about it, this is not too different than the "unmanaged" code case.
Well there is some byte coding verification. For example if you manipulate MSIL so that you create calls to private members (something that you can't compile with VS.NET) you will get a runtime error saying that you tried to access a private member. So in this case there is some verification. What I found surprising was how little verification was done by the CLR when verification is disabled, see for example these issues: * Possible Type Confusion issue in .Net 1.1 (only works in Full Trust) <http://owasp.net/blogs/dinis_cruz/archive/2005/11/08/36.aspx> * Another Full Trust CLR Verification issue: Exploiting Passing Reference Types by Reference <http://owasp.net/blogs/dinis_cruz/archive/2005/12/28/393.aspx> * Another Full Trust CLR Verification issue: Changing Private Field using Proxy Struct <http://owasp.net/blogs/dinis_cruz/archive/2005/12/28/394.aspx> * Another Full Trust CLR Verification issue: changing the Method Parameters order <http://owasp.net/blogs/dinis_cruz/archive/2005/12/26/390.aspx> * C# readonly modifier is not inforced by the CLR (when in Full Trust <http://owasp.net/blogs/dinis_cruz/archive/2005/12/26/390.aspx> * Also related: JIT prevents short overflow (and PeVerify doesn't catch it) <http://owasp.net/blogs/dinis_cruz/archive/2006/01/10/422.aspx> and ANSI/UNICODE bug in System.Net.HttpListenerRequest <http://www.owasp.net//blogs/dinis_cruz/archive/2005/12/17/349.aspx> Basically, Microsoft decided against performing verification on Full Trust code (which is 99% of the .Net code out there remember). Their argument (I think) is: "if it is Full Trust then it can jump to unmanaged code anyway, so all bets are off" (I am sure I have seen this documented somewhere in a Microsoft book, KB article or blog, but can't seem to find it (for the Microsofties that are reading this (if any), can you post some links please? thanks)) Apart from a basic problem which is "You cannot trust Full Trust code EVEN if it doesn't make ANY direct unmanaged call or reflection" there is a much bigger one. When (not if) Applications start to be developed so that they run in secure Partially Trusted environments,I think that the developers will find that they code will suffer from an immediate performance hit due to the fact that Verification is now being done on their code (again for the Microsofties that are reading this (if any), can you post some data related to the performance impact of the current CLR Verification process? thanks)
Apparently the whole "managed" versus "unmanaged" code only has to do with whether or not garbage collection is attempted.
yes, although I still think that we should fight for the words "Managed Code" to include verification
However, the real question is "is this true for ALL managed code or only managed code in the .NET Framework"?
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/)
Of course if software quality improvement does not take place in these companies, their signing would be somewhat vacuous. Butit would be better than nothing, since at least all such code would not be fully trusted by default.
Yes, and note that I strongly defend that: "All local code must NOT be given Full Trust by default" (at the moment it is) Dinis PS: For the Microsofties that are reading this (if any) .... sorry for the irony and I hope I am not offending anyone, but.... WHEN are you going to join this conversion? (i.e. reply to this posts) I can only see 4 reasons for your silence: a) you are not reading these emails, b) you don't care about these issues, c) you don't want to talk about them or d) you don't know what to say. Can you please engage and publicly participate in this conversation ... Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20060327/dc79b065/attachment.html
Current thread:
- 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code Wall, Kevin (Mar 25)
- [Owasp-dotnet] RE: 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code Dinis Cruz (Mar 26)