.NET Framework 1.1 Security Guidelines - Unmanaged Code

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan


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." at http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh21.asp

Personal tools