Unmanaged Code

If you have existing COM components or Win32 DLLs that you want to reuse, use the Platform Invocation Services (P/Invoke) or COM Interop layers . When you call unmanaged code, it is vital that your managed code validates each input parameter passed to the unmanaged API to guard against potential buffer overflows. Also, be careful when handling output parameters passed back from the unmanaged API.

You should isolate calls to unmanaged code in a separate wrapper assembly. This allows you to sandbox the highly privileged code and to isolate the code access security permission requirements to a specific assembly. For more details about sandboxing and about additional code access security related guidelines that you should apply when calling unmanaged code, see "Unmanaged Code" in Chapter 8, "Code Access Security in Practice." The following recommendations help improve the security of your unmanaged API calls, without using explicit code access security coding techniques:

• Validate input and output string parameters .

• Validate array bounds .

• Check file path lengths .

• Compile unmanaged code with the /GS switch .

• Inspect unmanaged code for "dangerous" APIs .

Validate Input and Output String Parameters

String parameters passed to unmanaged APIs are a prime source of buffer overflows. Check the length of any input string inside your wrapper code to ensure it does not exceed the limit defined by the unmanaged API. If the unmanaged API accepts a character pointer you may not know the maximum permitted string length, unless you have access to the unmanaged source. For example, the following is a common vulnerability.

 void SomeFunction( char *pszInput ) {   char szBuffer[10];   // Look out, no length checks. Input is copied straight into the buffer   // Check length or use strncpy   strcpy(szBuffer, pszInput);   . . . } 

If you cannot examine the unmanaged code because you do not own it, make sure that you rigorously test the API by passing in deliberately long input strings.

If your code uses a StringBuilder to receive a string passed from an unmanaged API, make sure that it can hold the longest string that the unmanaged API can hand back.

Validate Array Bounds

If you pass input to an unmanaged API using an array, check that the managed wrapper verifies that the capacity of the array is not exceeded.

Check File Path Lengths

If the unmanaged API accepts a file name and path, check that it does not exceed 260 characters . This limit is defined by the Win32 MAX_PATH constant. It is very common for unmanaged code to allocate buffers of this length to manipulate file paths.

Note  

Directory names and registry keys can only be a maximum of 248 characters long.

Compile Unmanaged Code With the /GS Switch

If you own the unmanaged code, compile it using the /GS switch to enable stack probes to help detect buffer overflows. For more information about the /GS switch, see Microsoft Knowledge Base article 325483, "WebCast: Compiler Security Checks: The -GS compiler switch."

Inspect Unmanaged Code for Dangerous APIs

If you have access to the source code for the unmanaged code that you are calling, you should subject it to a thorough code review, paying particular attention to parameter handling to ensure that buffer overflows are not possible and that it does not use potentially dangerous APIs. For more information see Chapter 21, "Code Review."