BIG PROBLEM WITH SecurityCriticalAttribute - it's simply can be avoided with Reflection - by fagim

Status : 


Sign in
to vote
ID 767152 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 10/12/2012 1:30:13 AM
Access Restriction Public


Due to

Transparent code cannot use reflection to access security-critical members, even if the code is fully trusted. A MethodAccessException, FieldAccessException, or TypeAccessException is thrown.

Code that is running with partial trust is treated as transparent.

But in code, provided as REPRODUCE i show, that it's not true:
Reflection CAN use anything in SecurityCritical code from SecurityTransparent!!!!
Sign in to post a comment.
Posted by fagim on 12/6/2012 at 11:08 PM
Thx for explanation, but it's discouraged. What's real benefit to protect compile-time only??? Real-world exploits and other unsecure stuff are based on runtime, not compile time. And you haven't answerd how to deny usage of reflection for partial trusted code? Where now (after CAS died) i can make it well?
CAS died, SecuritySafe attributes are just flags for compiler, no runtime protection added, no common way to permit reflection usage, how can I secure host from plugins except of SANDBOX with exposing as MarshallByRef objects just secure-safe objects????
Posted by Shawn [MSFT] on 11/14/2012 at 3:45 PM
The security transparency model is enforced at code generation time. This means that when the JIT compiles a call from a transparent method to a native method, it inserts the security enforcement code. For late bound invocation, such as reflection invocation, enforcement cannot happen at compile time and must happen at runtime.

When a reflection invocation happens onto a security critical method, then we need to examine the security context this happens in. This is done by triggering a full security demand from the reflection code, which will fail if any partially trusted code is on the stack or if the reflection is done in a partially trusted domain.

In the example given, if the program was run in a partially trusted AppDomain, you would see that a SecurityException is triggered by the reflection. Note that this is the same enforcement model of other static checks being done dynamicaly via reflection (for instance, reflecting onto private fields or reflecting onto a method with a LinkDemand).

In your example, also note that SecurityCriticalLibrary is all critical since there is no assembly level transparency attribute. You probably want to do [assembly: AllowPartiallyTrustedCallers] there in order to have your SecuritySafeCritical attributes take effect.
Posted by Helen [MSFT] on 10/12/2012 at 1:58 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Macy [MSFT] on 10/12/2012 at 1:50 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(