Your debugging code can be a security vulnerability: Loading optional debugging DLLs without a full path

Remember, the bad guys don't care that your feature exists just for debugging purposes. If it's there, they will attack it.

Consider the following code:

DOCLOADINGPROC g_pfnOnDocLoading;

void LoadDebuggingHooks()
{
HMODULE hmodDebug = LoadLibrary(TEXT("DebugHooks.dll"));
if (!hmodDebug) return;
g_pfnOnDocLoading = (DOCLOADINGPROC)
              GetProcAddress(hmodDebug, "OnDocLoading");
...
}

HRESULT LoadDocument(...)
{
...
if (g_pfnOnDocLoading) {
  // let the debugging hook replace the stream
  g_pfnOnDocLoading(&pstmDoc);
}
...
}
When you need to debug the program, you can install the DebugHooks.dll DLL into the application directory. The code above looks for that DLL and if present, gets some function pointers from it. For illustrative purposes, I've included one debugging hook. The idea of this example (and it's just an example, so let's not argue about whether it's a good example) is that when we're about to load a document, we call the OnDocLoading function, telling it about the document that was just loaded. The OnDocLoading function wraps the IStream inside another object so that the contents of the document can be logged byte-by-byte as it is loaded, in an attempt to narrow down exactly where document loading fails. Or it can be used for testing purposes to inject I/O errors into the document loading path to confirm that the program behaves properly under those conditions. Use your imagination.

Read more: The old new thing

Posted via email from .NET Info