Understanding .NET Framework Security

1. Understanding .NET Framework Security David LeBlancMicrosoft Office

2. Agenda • .NET Framework Security Fundamentals • Evidence • Permissions • Policy • .NET Framework security administration • Needed for setup • When to use .NET Framework vs. core OS security

3. Why Is This Important? Understanding managed code security will help you make better decisions about when to use managed vs. unmanaged code • Framework security can cause bugs • Code running locally isn’t the same as code running from a share

4. What .NET Is and Isn’t • .NET IS a great new toolset • Can be used to solve previously unmanageable security problems • Largely eliminates buffer overruns • Allows a system or host application to restrict the capabilities of managed code

5. .NET IS NOT a Silver Bullet • A majority of security mistakes are language-independent • Bad design is still bad design • New capabilities provided by .NET can be misused • New, improved ways to make security mistakes! • Code running as fully trusted is just as dangerous as a native binary!

6. User and Code Identity Security • Classic OS security is based on limiting the capabilities of a user or group • Still an effective mechanism • Does not help when code is either untrusted or semi-trusted • Code Identity Security • Allows a user or admin to define the level of trust granted based on things we know about the code • To be most effective, use both approaches together

7. Permissions Assembly HostingApp Domain Evidence Policy How Permissions Are Resolved

8. PermissionsGranted Assembly RequiredPermissions Invokes a method Exception! Allowed! How Permissions Are Used

9. Quick .NET Framework Refresh • Assemblies • Logicalcollection of one or more EXE or DLL files containing code & resources • Can be a single file (EXE or DLL) • Can be a logical (not physcial) collection of more than one file residing in the same directory • Stored in either the Global Assembly Cache, or the local app directory

10. Identifying Assemblies – Stong Names • An assembly contains a manifest • Describes global attributes and layout • Publisher, assembly name, version, … • Contains the public key of the signer • A strong named assembly is signed • Signatures don’t use a third party • No automatic means to associate signature key with the publisher • No revocation mechanism

11. Uses of Strong Names • Only strong named assemblies can be loaded into the global catalogue • Strong names allow multiple versions of an assembly to co-exist • No “DLL Hell” • Protects against tampering • Permissions can be assigned to strong names • Useful for interface and inheritance restrictions • Required to allow partially trusted callers

12. Operating System .NET Framework Job Object App Domain Process Assembly Assembly Application Domains Native Execution Managed Code

13. Application Domains • App domains contain one or more assemblies • App domain created by a host • If a specific app domain isn’t created, assemblies get loaded into the default domain • Useful when you want to provide fewer rights than provided by default policy • Browser Host • Custom Host • Server Host (ASP.NET) • Also used when loading an assembly you’d like to unload later

14. Evidence • Evidence applies to the code, not the user running the code • Applied to an assembly or app domain • Two types of evidence • Host-provided evidence • Assembly-provided evidence • Evidence changes when code is run from different places!

15. Host-Provided Evidence • Application Directory • Directory the code is running from • Hash • Typically a SHA1 or MD5 hash of the assembly • PermissionRequestEvidence • Permissions requested by the assembly • Only visible during policy resolution • Publisher • Authenticode signature

16. Host-Provided Evidence (2) • Site • Web site of origin • StrongName • A cryptographically strong binding of a name, version and culture • URL • URl of origin • Zone • IE security zone for the assembly

17. Evidence Example Local: Host Evidence: <Url>file://C:/projects/CSharpCruft/bin/Release/CSharpCruft.exe</Url> <Zone>MyComputer</Zone> From a share: Host Evidence: <Url>file://BYTEME/C$/projects/CSharpCruft/bin/Release/CSharpCruft.exe <Zone>Intranet</Zone>

18. Assembly-Provided Evidence • Allows an assembly to provide custom evidence • Cannot override any default host-provided evidence • If host evidence is included in an assembly it is ignored by the .NET runtime • Can be any type of data, from a simple integer to a signed XML statement

19. Assigning Privileges • Security Policy maps code identity to privileges • Evidence defines identity • Membership Conditions • Represented by extensible objects • Determines membership given evidence as input • Code Groups • Hierarchal mapping between policy and membership conditions • Policy Levels • Contains a permission set, code group and “full trust” assembly list

20. Policy – Membership Conditions • Determines whether an assembly is a member of a group based on evidence • Implements IMembershipCondition • Can be customized – useful with custom evidence classes • Default membership condition classes • HashMembershipCondition • SiteMembershipCondition • ZoneMembershipCondition • Etc, etc.

21. Policy – Code Groups • Constructed from a membership condition and a PolicyStatement • PolicyStatement contains: • PermissionSet • Attributes • Exclusive – any assembly matching membership condition receives permissions only from this code group • LevelFinal – No lower level groups are evaluated • All – Exclusive and LevelFinal • Nothing – not Exclusive or LevelFinal

22. Policy – Policy Levels • Four Policy Levels exist: • Enterprise • Machine • User • App Domain • Resulting permissions are the intersection of the permissions from all policies • Allows lower levels to set policies more restrictive than upper levels • Unless LevelFinal attribute encountered

23. Resolving Permissions • For each Policy Level • Membership conditions are resolved • Permission set is intersection of permissions for code groups for the assembly • If LevelFinal is encountered, lower levels are not evaluated • Each lower level can reduce permissions • Lower levels cannot increase permissions

24. Permissions • Types of Permissions: • Code Access Permissions • Standard permissions derived from System.Security.CodeAccessPermission • Identity Permissions • Represents evidence • Zone evidence creates a ZoneIdentityPermission • Custom Permissions • Could be App Domain specific

25. Using Permissions • Granted by security policy • Policy states that any assembly that provides certain evidence is allowed specific permissions • Permission demands • Used by trusted code to require permissions of semi-trusted callers

26. Stating Permission Requirements • Declarative • Stored in an assembly’s metadata • Available at load time • Can be placed at class or method level • Easily reviewed by a host • Imperative • Requires permissions at run-time • Allows more complex logic • Permission Sets • Any operation that can be performed on a single privilege can be performed on a set • Increases performance

27. Walking the Stack • A Stack Walk is triggered when a permission is required to continue • Designed to overcome luring attacks • Ensures that the original caller has enough permissions to perform an action

28. Asserting Permissions • Assert stops the stack walk in your code for the permission asserted • No effect on other permissions • Must be used with care • Claims that you can allow semi-trusted callers to perform higher-level actions safely

29. Denying Permissions • Deny also stops the stack walk immediately • Throws a security exception when encountered • Rarely useful in practice, except in testing • When creating custom permissions be sure and test negative case • PermitOnly • Allows request only if the requested set of permissions is a subset of the allowed set • Can be useful in hosting applications and testing

30. Class and Method Permissions • LinkDemand – used to restrict the callers of public methods • InheritanceDemand – used to restrict which code can inherit from your assembly

31. Design Scenarios • Security-neutral code • Does nothing with the security subsystem • Must typically be installed locally • Few advantages over native code • Non-reusable application • Should take steps to ensure semi-trusted callers are blocked • Managed wrapper over native code • Needs to be carefully validated • Similar problem to an ActiveX control • Library code that exposes protected resources • Must take care to demand appropriate permissions • Code and design must be carefully evaluated

32. Development Considerations • Principle of Least Privilege • Ask for the permissions your assembly requires • Explicitly refuse all other permissions • Protects you from coding and design errors by limiting your assembly • Read The Fine Manual! • Read “Secure Coding Guidelines” in .NET Framework SDK • User input is just as evil as it was with native code!

33. Securing Methods • If another assembly calls into your object, the methods it calls must be public • Not all public methods need to be available to all users • Similar problem to undocumented DLL exports • Solutions • Limit scope of methods when possible • Require callers to have a specific identity • Use inheritance demands to limit sub-classes • Can be used to restrict which methods can be overridden

34. Tricks and Traps • LinkDemand • Only checks the immediate caller during JIT • If a LinkDemand is required on a derived method, it must also be required on the base method • Assembly.Load • Loads an assembly using the evidence of the caller, NOT the assembly being loaded

35. Conclusions • Managed code is a great tool • Like all tools, you have to understand how they work • Managed code is NOT a silver bullet • It is possible to create security holes in any language • .NET Security adds complexity • Differences in execution context can create large differences in how your code runs

36. Additional Resources • .NET Framework Security • LaMacchia, Lange, Lyons, Martin and Price • .NET Framework SDK • Secure Coding Guidelines • Writing Secure Code, 2nd Edition

37. © 2006 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.