{"id":12313,"date":"2010-11-10T07:00:00","date_gmt":"2010-11-10T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2010\/11\/10\/your-debugging-code-can-be-a-security-vulnerability-loading-optional-debugging-dlls-without-a-full-path\/"},"modified":"2010-11-10T07:00:00","modified_gmt":"2010-11-10T07:00:00","slug":"your-debugging-code-can-be-a-security-vulnerability-loading-optional-debugging-dlls-without-a-full-path","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20101110-00\/?p=12313","title":{"rendered":"Your debugging code can be a security vulnerability: Loading optional debugging DLLs without a full path"},"content":{"rendered":"

\nRemember, the bad guys don’t care that your feature exists\n\njust for debugging purposes<\/a>.\nIf it’s there, they will attack it.\n<\/p>\n

\nConsider the following code:\n<\/p>\n

\nDOCLOADINGPROC g_pfnOnDocLoading;\nvoid LoadDebuggingHooks()\n{\n HMODULE hmodDebug = LoadLibrary(TEXT(\"DebugHooks.dll\"));\n if (!hmodDebug) return;\n g_pfnOnDocLoading = (DOCLOADINGPROC)\n               GetProcAddress(hmodDebug, \"OnDocLoading\");\n ...\n}\nHRESULT LoadDocument(...)\n{\n ...\n if (g_pfnOnDocLoading) {\n   \/\/ let the debugging hook replace the stream\n   g_pfnOnDocLoading(&pstmDoc);\n }\n ...\n}\n<\/pre>\n
\nWhen you need to debug the program, you can install the\nDebugHooks.dll<\/code> DLL into the application directory.\nThe code above looks for that DLL and if present, gets\nsome function pointers from it.\nFor illustrative purposes, I’ve included one debugging hook.\nThe idea of this example\n(and it’s just an example,\nso let’s not argue about whether it’s a good example)\nis that when we’re about to load a document,\nwe call the OnDocLoading<\/code> function,\ntelling it about the document that was just loaded.\nThe OnDocLoading<\/code> function\nwraps the IStream<\/code> inside another object\nso that the contents of the document can be logged\nbyte-by-byte as it is loaded, in\nan attempt to narrow down exactly where document loading fails.\nOr it can be used for testing purposes to inject I\/O errors\ninto the document loading path to confirm that the program\nbehaves properly under those conditions.\nUse your imagination.\n<\/p>\n
\nBut this debugging code is also a security vulnerability.\n<\/p>\n
\nRecall that the library search path searches directories\nin the following order:\n<\/p>\n
    \n
  1. The directory containing the application EXE.\n<\/li>\n
  2. The system32 directory.\n<\/li>\n
  3. The system directory.\n<\/li>\n
  4. The Windows directory.\n<\/li>\n
  5. The current directory.\n<\/li>\n
  6. The PATH.\n<\/li>\n<\/ol>\n
    \nWhen debugging your program, you install DebugHooks.dll<\/code>\ninto the application directory so that it is found in step 1.\nBut when your program isn’t being debugged,\nthe search in step 1 fails,\nand the search continues in the other directories.\nThe DLL is not found in steps 2 through 4,\nand then we reach step 5: The current directory.\n<\/p>\n
    \nAnd now you’re pwned.\n<\/p>\n
    \nYour application typically does not have direct control over\nthe current directory.\nThe user can run your program from any directory,\nand that directory ends up as your current directory.\nAnd then your LoadLibrary<\/code> call searches\nthe current directory,\nand if a bad guy put a rogue DLL in the current directory,\nyour program just becames the victim of code injection.\n<\/p>\n
    \nThis is made particularly dangerous when your application\nis associated with a file type,\nbecause the user can run your application just by\ndouble-clicking an associated document.\n<\/p>\n
    \nWhen you double-click a document, Explorer sets the\ncurrent directory of the document handler application\nto the directory that contains the document being opened.\nThis is necessary for applications which look around\nin the current directory for supporting files.\nFor example,\nconsider\na hypothetical application LitWare Writer<\/code>\nassociated with *.LIT<\/code> files.\nA LitWare Writer document\nABC.LIT<\/code> file is really just the representative\nfor a family of files,\nABC.LIT<\/code> (the main document),\nABC.LTC<\/code> (the document index and table of contents),\nABC.LDC<\/code> (the custom spell check dictionary for the document),\nABC.LLT<\/code> (the custom document layout template),\nand so on.\nWhen you open the document C:\\PROPOSAL\\ABC.LIT<\/code>,\nLitWare Writer looks for the other parts of your document\nin the current directory,\nrather than in C:\\PROPOSAL<\/code>.\nTo help these applications find their files,\nExplorer specifies to the CreateProcess<\/code> function\nthat it should set the initial current directory of\nLitWare Writer to C:\\PROPOSAL<\/code>.\n<\/p>\n
    \nNow, you might argue that programs like LitWare Writer\n(which look for the ancillary files of a multi-file document\nin the current directory instead of the directory containing\nthe primary file of the multi-file document) are\npoorly-written, and I would agree with you,\nbut Windows needs to work even with poorly-written programs.\n(Pre-emptive snarky comment<\/b>: Windows is itself\na poorly-written program.)\nThere are a lot of poorly-written programs out there,\nsome of them industry leaders in their market (see above\npre-emptive snarky comment<\/b>)\nand if Windows stopped accommodating them, people would\nsay it was the fault of Windows and not the programs.\n<\/p>\n
    \nI can even see in my mind’s eye the bug report that resulted\nin this behavior being added to the MS-DOS Executive:\n<\/p>\n
    \n“This program has worked just fine in MS-DOS,\nbut in Windows, it doesn’t work.\nStupid Windows.”\n<\/p>\n
    \nCustomers tend not to be happy with the reply,\n“Actually, that program has simply been lucky for the past X years.\nThe authors of the program never considered the case where\nthe document being opened is not in the current directory.\nAnd it got away with it, because the way you opened the document\nwas to use the chdir<\/code> command to move to the directory\nthat contained your document,\nand then to type\nLWW ABC.LIT<\/code>.\nIf you had ever done\nLWW C:\\PROPOSAL\\ABC.LIT<\/code> you would have run into the\nsame problem.\nThe behavior is by design.”\n<\/p>\n
    \nIn response to “The behavior is by design” is usually\n“Well, a design that prevents me from getting my work done is\na crappy design.”\nor a much terser “No it’s not, it’s a bug.”\n(Don’t believe me? Just read Slashdot.)\n<\/p>\n
    \nSo to make these programs work in spite of themselves,\nthe MS-DOS Executive sets the current directory of the program\nbeing launched to the directory containing the document itself.\nThis was not an unreasonable decision because it gets the program\nworking again, and it’s not like the program cared about the\ncurrent directory it inherited from the MS-DOS Executive,\nsince it had no control over that either!\n<\/p>\n
    \nBut it means that if you launched a program by double-clicking\nan associated document, then unless that program takes steps to\nchange its current directory, it will have the document’s containing\nfolder as its current directory, which prevents you from deleting\nthat directory.\n<\/p>\n
    \nBonus chatter<\/b>:\nI wrote this series of entries nearly two years ago,\nand even then,\nI didn’t consider this to be anything particularly groundbreaking,\nbut apparently some people rediscovered it a few months ago\nand are falling all over themselves to claim credit\nfor having found it first.\nIt’s like a new generations of teenagers who think they invented sex.\nFor the record, here is some\n\nofficial guidance<\/a>.\n(And just to be clear,\nthat’s official guidance on the current directory attack,\nnot\n\nofficial guidance on sex<\/a>.)\n<\/p>\n
    \nHistory chatter<\/b>:\nWhy is the current directory even considered at all?\nThe answer goes back to CP\/M.\nIn CP\/M, there was no PATH.\nEverything executed from the current directory.\nThe rest is a chain of backward compatibility.<\/p>\n","protected":false},"excerpt":{"rendered":"
    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 […]<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[26],"class_list":["post-12313","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-other"],"acf":[],"blog_post_summary":"
    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 […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/12313","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=12313"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/12313\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=12313"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=12313"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=12313"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}