full-disclosure - 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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon Mar 27 04:03:57 2006
From: dinis at ddplus.net (Dinis Cruz)
Subject: 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

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://lists.grok.org.uk/pipermail/full-disclosure/attachments/20060327/dc79b065/attachment-0001.html