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

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

Closed

Type:	Bug
ID:	767152
Opened:	10/12/2012 1:30:13 AM
Access Restriction:	Public

Workaround(s)

view

User(s) can reproduce this bug

Due to http://msdn.microsoft.com/en-us/library/stfy7tfc(v=vs.100).aspx

"
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:
ONLY USUAL CALLS TO DEFENDED CLASSES/MEMBERS are served with this,
Reflection CAN use anything in SecurityCritical code from SecurityTransparent!!!!

Details (expand)

.NET Framework 4.5

// 1:Build DLL with secret classes and accessor classes :

using System;
using System.Collections.Generic;
using System.Linq;
using System.Security;
using System.Text;
using security_critical_library;

namespace security_critical_library
{
    [SecurityCritical]
    class MainInternalClass {
        [SecurityCritical]
        static readonly int __secret;
        static MainInternalClass() {
            __secret = new Random().Next();
        }

        public int Secret { get { return __secret; } }
    }
    [SecuritySafeCritical]
    public class Accessor {
        [SecuritySafeCritical]
        public Accessor() {

        }
        [SecurityCritical]
        public int GetSecretForInternals() {
            return new MainInternalClass().Secret;
        }
        [SecuritySafeCritical]
        public int GetSecretForPublic() {
            return new MainInternalClass().Secret + 10000;
        }
    }
}

//2: Build console application:

using System;
using System.Reflection;
using System.Security;
using security_critical_library;
[assembly : SecurityTransparent]
namespace legal_app
{
    class Program
    {
        static void Main() {
            Console.WriteLine("I AM ANGEL, FOR NOW");
            Console.WriteLine("try get public acess");
            try {
                Console.WriteLine(new Accessor().GetSecretForPublic());
            }catch(Exception) {
                Console.WriteLine("Oops! Why I cannot use method marked as SecuritySafeCritical ????");
            }
            Console.WriteLine("OK");
            Console.WriteLine("try get internal acess");
            try {
                Console.WriteLine(new Accessor().GetSecretForInternals());
            }catch(Exception) {
                Console.WriteLine("oooo.... it's protected");
                Console.WriteLine("YEAH, I'M ENTERED HACKED MODE AND I WANT MORE!!!! I'LL HACK YOUR SECRET!!!");
                var type = typeof(Accessor).Assembly.GetType("security_critical_library.MainInternalClass");
                Console.WriteLine("i see your secret: "+type);
                var fld = type.GetField("__secret", BindingFlags.Static | BindingFlags.NonPublic | BindingFlags.GetField);
                Console.WriteLine("i catch your secret: " + fld.Name);
                var value = fld.GetValue(null);
                Console.WriteLine("i read your secret!!!: "+value);
                fld.SetValue(null,int.MaxValue);
                Console.WriteLine("i have hacked your secret!!! AND CHANGE IT");
                Console.WriteLine("U-HA-HA I'M SECURITY TRANSPARENT!!!!!!!!!!!!!!");
            }

        }
    }
}

//3: Compile and run console AND SEE WHAT IT DOES!!!!!

English

Windows 7 SP1

Russian

In usual calling mode application have valid permissions.

But with REFLECTION it can DO ANYTHING

And for another hand - application cannot reach method published as SecuritySafeCriticall CANNOT BE called while it have to be callable

As it documented -
I expect Exceptions are thrown in any case where non-trusted code try reach specially protected with SecurityCritical code

I expect that non-trusted Transparent code can access SecuritySafeCritical memebers - here .ctor of Accessor is still not avail for calling

It's especially expected while CAS became obsolete

File Name	Submitted By	Submitted On	File Size
security_critical_library.zip	fagim	10/12/2012	6 KB
MainInternalClass.cs	fagim	10/12/2012	433 bytes
Program.cs	fagim	10/12/2012	1 KB
MainInternalClass.cs	fagim	10/12/2012	433 bytes

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 Microsoft 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 Microsoft 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 Microsoft 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(http://support.microsoft.com)