This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Difference between revisions of "Microsoft's Comments on the Full Trust Type Safety issues"

Jump to: navigation, search
(Reverting to last version not containing links to
Line 1: Line 1:
| type=historical
| link=:Category:OWASP_.NET_Project
'''From:''' "Microsoft Security Response Center" <[email protected]><br/>
'''From:''' "Microsoft Security Response Center" <[email protected]><br/>
'''Sent:''' Monday, December 26, 2005 7:26 PM<br/>
'''Sent:''' Monday, December 26, 2005 7:26 PM<br/>

Latest revision as of 01:30, 22 July 2014

This historical page is now part of the OWASP archive.
This page contains content that is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were once valid but may now link to sites or pages that no longer exist.
Please use the newer Edition(s) like Category:OWASP_.NET_Project

From: "Microsoft Security Response Center" <[email protected]>
Sent: Monday, December 26, 2005 7:26 PM
To: [email protected]
Subject: RE: Possible Type Confusion issue in .Net 1.1 (only works in Full Trust)

Hi Dinis,

I trust you had or are having a great holiday season.

Thanks for heads up on your blog posting, I've received the following feedback from the product team, seems this topic has come up before.

Some people have argued that Microsoft should always enforce type safety at runtime (i.e. run the verifier) even if code is "Fully Trusted". We've chosen not to do this for a number of reasons (e.g. historical, perf, etc). There are at least two important things to consider about this scenario:

1) Even if we tried to enforce type safety using the verifier for Fully Trusted code, it wouldn't prevent Fully Trusted from accomplishing the same thing in 100 other different ways. In other words, your example accessed an object as if it were a different incompatible type - The verifier could have caught this particular technique that allowed him to violate type safety. However, he could have accomplished the same result using private reflection, direct memory access with unsafe code, or indirectly doing stuff like using PInvoke/native code to disable verification by modifying the CLR's verification code either on disk or in memory. There would be a marginal benefit to insuring people wrote "cleaner" more "type safe" code by enforcing verification at runtime for Full Trust, but you wouldn't get any additional security benefits because you can perform unverifiable actions in dozens of ways the verifier won't prevent if you are Fully Trusted.

2) As mentioned at the end of #1 above, one argument is that it's good for programmers (even fully trusted ones) to follow type safety rules, and doing runtime verification would keep peoplewriting cleaner code. However, we don't need to do the verification at "runtime" in order to encourage good type safety hygiene. Instead, we can rely on our languages to do this for us. For example, C# and VB by default ensure that you produce verifiable code. If you've written your code in a language like C#, you're not going to run into cases where you've accidentally created unverifiable code (This can be seen in the example posted on the blog since you needed to use the low level assembler to hack up a program initially compiled in C#). Given that you can't prevent Fully Trusted code from doing unverifiable things at runtime, there's only a marginal difference between encouraging type safety at compile time vs at runtime for the Fully Trusted code developer.

I hope that helps to convey the message on where Microsoft stands with this issue.

Kind Regards Scott D.