unmanagedcodesecuritycodereview

Return to HomePage

Unmanaged Code from Managed Code Security Review

Note: See online on MSDN: http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh21.asp

Give special attention to code that calls unmanaged code, including Win32 DLLs and COM objects, due to the increased security risk. Unmanaged code is not verifiably type safe and introduces the potential for buffer overflows. Resource access from unmanaged code is not subject to code access security checks. This is the responsibility of the managed wrapper class.
Generally, you should not directly expose unmanaged code to partially trusted callers. For more information about the issues raised in this section, see the "Unmanaged Code" sections in Chapter 7, "Building Secure Assemblies," and Chapter 8, "Code Access Security in Practice."
Use the following review questions to validate your use of unmanaged code:

* Do you assert the unmanaged code permission?
* If so, check that your code demands an appropriate permission prior to calling the Assert method to ensure that all callers are authorized to access the resource or operation exposed by the unmanaged code. For example, the following code fragment shows how to demand a custom Encryption permission and then assert the unmanaged code permission:

		 // Demand custom [EncryptionPermission.]
		 (new [EncryptionPermission(]
		         [EncryptionPermissionFlag.Encrypt,] storeFlag)).Demand();
		 // Assert the unmanaged code permission.
		 (new [SecurityPermission(SecurityPermissionFlag.UnmanagedCode)).Assert();]
		 // Now use P/Invoke to call the unmanaged DPAPI functions.

For more information see "Assert and RevertAssert" in Chapter 8, "Code Access Security in Practice."
* Do you use SuppressUnmanagedCodeAttribute?
* This attribute suppresses the demand for the unmanaged code permission issued automatically when managed code calls unmanaged code. If P/Invoke methods or COM interop interfaces are annotated with this attribute, ensure that all code paths leading to the unmanaged code calls are protected with security permission demands to authorize callers. Also check that this attribute is used at the method level and not at the class level.

Note: Adding a SupressUnmanagedCodeSecurityAttribute turns the implicit demand for the UnmanagedCode permission issued by the interop layer into a LinkDemand. Your code is vulnerable to luring attacks.

* Is the unmanaged entry point publicly visible?
* Check that your unmanaged code entry point is marked as private or internal. Callers should be forced to call the managed wrapper method that encapsulates the unmanaged code.
* Do you guard against buffer overflows?
* Unmanaged code is susceptible to input attacks such as buffer overflows. Unmanaged code APIs should check the type and length of supplied parameters. However, you cannot rely on this because you might not own the unmanaged source. Therefore, the managed wrapper code must rigorously inspect input and output parameters. For more information, see "Buffer Overflows" in this chapter.

Note: All code review rules and disciplines that apply to C and C++ apply to unmanaged code.

* Do you range check enumerated types?
* Verify that all enumerated values are in range before you pass them to a native method.
* Do you use naming conventions for unmanaged code methods?
* All unmanaged code should be inside wrapper classes that have the following names: NativeMethods, UnsafeNativeMethods, and SafeNativeMethods. You must thoroughly review all code inside UnsafeNativeMethods and parameters that are passed to native APIs for security vulnerabilities.
* Do you call potentially dangerous APIs?
* You should be able to justify the use of all Win32 API calls. Dangerous APIs include:
* Threading functions that switch security context
* Access token functions, which can make changes to or disclose information about a security token
* Credential management functions, including functions that creates tokens
* Crypto API functions that can decrypt and access private keys
* Memory Management functions that can read and write memory
* LSA functions that can access system secrets

Return to HomePage