Unsafe Native Invoke

Improper use of the Platform Invocation Services can render managed applications vulnerable to security flaws in other languages.

Unsafe Native Invoke errors occur when a managed application uses P/Invoke to call native (unmanaged) code written in another programming language.

Example 1: The following C# code defines a class named Echo. The class declares one native method that uses C to echo commands entered on the console back to the user.

class Echo
{
  [DllImport("mylib.dll")]
  internal static extern void RunEcho();

  static void main(String[] args)
  {
    RunEcho();
  }
}

The following C code defines the native method implemented in the Echo class:

#include <stdio.h>

void __stdcall RunEcho()
{
  char* buf = (char*) malloc(64 * sizeof(char));
  gets(buf);
  printf(buf);
}

Because the Echo is implemented in managed code, it may appear that it is immune to memory issues like buffer overflow vulnerabilities. Although the managed environment does do a good job of making memory operations safe, this protection does not extend to vulnerabilities occurring in native code accessed using P/Invoke. Despite the memory protections offered in the managed runtime environment, the native code in this example is vulnerable to a buffer overflow because it makes use of gets(), which does not perform any bounds checking on its input. As well, buf is allocated but not freed and therefore is a memory leak.

The vulnerability in Example 1 could easily be detected through a source code audit of the native method implementation. This may not be practical or possible depending on the availability of source code and the way the project is built, but in many cases it may suffice. However, the ability to share objects between the managed and native environments expands the potential risk to much more insidious cases where improper data handling in managed code may lead to unexpected vulnerabilities in native code or to unsafe operations in native code corrupting data structures in managed code.

Vulnerabilities in native code accessed through a managed application are typically exploited in the same manner as they are in applications written in the native language. The only challenge to such an attack is for the attacker to identify that the managed application uses native code to perform certain operations. This can be accomplished in a variety of ways, including identifying specific behaviors that are often implemented with native code or by exploiting a system information leak in the managed application that exposes its use of P/Invoke.