Full Disclosure mailing list archives
Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code
From: Dinis Cruz <dinis () ddplus net>
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
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- RE: [SC-L] 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)
- Buffer OverFlow in ILASM and ILDASM Dinis Cruz (Mar 26)
- Re: [Owasp-dotnet] RE: [SC-L] 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)
- RE: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code Jeff Williams (Mar 26)
- Re: RE: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code KF (lists) (Mar 26)
- Re: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code Stephen de Vries (Mar 27)
- Re: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code Dinis Cruz (Mar 28)
- RE: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code Eric Swanson (Mar 27)
- Re: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code Dinis Cruz (Mar 28)
- RE: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code Jeff Williams (Mar 26)
- Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code Dinis Cruz (Mar 28)
- RE: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code Eric Swanson (Mar 28)
- RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code Eric Swanson (Mar 28)
- Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code Gunnar Peterson (Mar 29)
