Hi @ll,
(a long[er] form of the following advisory is available at
<https://skanthak.homepage.t-online.de/snafu.html>)
With Windows 10 1607, Microsoft introduced the /DEPENDENTLOADFLAG
linker option, a security feature to restrict or limit the search
path for DLLs:
| On supported operating systems, this option has the effect of
| changing calls to LoadLibrary("dependent.dll") to the equivalent
| of LoadLibraryEx("dependent.dll", 0, load_flags).
...
| This flag can be used to make DLL planting attacks[*] more difficult.
...
| An option of /DEPENDENTLOADFLAG:0x800 is even more restrictive,
| limiting search to the %windows%\system32 directory.
[*] DLL planting attacks referred to "Dynamic-Link Library Security"
<https://msdn.microsoft.com/en-us/library/ff919712.aspx>
The above quote was taken from
<https://docs.microsoft.com/en-us/cpp/build/reference/dependentloadflag>
before 2020-01-22; according to it /DEPENDENTLOADFLAG applies to
RUNTIME linking via LoadLibrary() ... which it but WRONG.
Demonstration:
~~~~~~~~~~~~~~
0. on a current installation of Windows 10, start the command prompt
of the Windows Development Kit and run the following two commands:
Set CL=/Iwindows.h /W4 /Zl
Set LINK=/DEPENDENTLOADFLAG:0x800 /DYNAMICBASE /NXCOMPAT /RELEASE /SUBSYSTEM:CONSOLE
1. build a minimal SNAFU.DLL from the following source file SNAFU.C
__declspec(dllexport)
BOOL WINAPI _DllMainCRTStartup(HANDLE hModule, DWORD dwReason, LPVOID lpReserved)
{
return TRUE;
}
with the following command:
CL.EXE /LD SNAFU.C /link /ENTRY:_DllMainCRTStartup /EXPORT:_DllMainCRTStartup
2. build a minimal application SNAFU.EXE from the following source
file SNAFU.C
__declspec(noreturn)
VOID WINAPI mainCRTStartup(VOID)
{
HMODULE hModule = LoadLibraryA("SNAFU.DLL");
if (hModule == NULL)
ExitProcess(GetLastError());
if (!FreeLibrary(hModule))
ExitProcess(GetLastError());
ExitProcess(0);
}
with the following command:
CL.EXE SNAFU.C /link /DEFAULTLIB:kernel32.lib /ENTRY:mainCRTStartup
3. run the application SNAFU.EXE and display its exit code with
the following commands:
.\SNAFU.EXE
Echo %ERRORLEVEL%
The exit code is 0, proving that /DEPENDENTLOADFLAG:0x800
does NOT limit the DLL search path for LoadLibrary() to
%SystemRoot%\System32\!
4. when you change the return value of the DLL's entry point
function _DllMainCRTStartup() to FALSE, the exit code is
1114 alias ERROR_DLL_INIT_FAILED, again proving that
/DEPENDENTLOADFLAG:0X800 does NOT work as documented above.
Due to its security impact (see "Dynamic-Link Library Security")
I reported this bug (plus two bugs in LINK.EXE, which fails to
set /DEPENDENTLOADFLAG in executable files; see the full story at
<https://skanthak.homepage.t-online.de/snafu.html>) to Microsoft's
Security Response Center, where MSRC Case 56011 was opened.
They replied to the bug demonstrated above with the following
statement, IGNORING the bugs reported against LINK.EXE completely:
| The team has finished their investigation and determined the way
| they will address this report is via a documentation update of
| https://docs.microsoft.com/en-us/cpp/build/reference/dependentloadflag?view=vs-2019.
|
| It wasn't supposed to say that LoadLibrary will act as LoadLibraryEx,
| specifically this statement:
|
| On supported operating systems, this option has the effect of
| changing calls to LoadLibrary("dependent.dll") to the equivalent
| of LoadLibraryEx("dependent.dll", 0, load_flags). Calls to
| LoadLibraryEx are unaffected. This option doesn't apply
| recursively to DLLs loaded by your app.
On 2020-01-24 the documentation update went live; it now reads:
| Sets the default load flags used when the operating system resolves
| the statically linked imports of a module.
|
| /DEPENDENTLOADFLAG[:load_flags]
|
| load_flags
| An optional integer value that specifies the load flags to apply
| when resolving statically linked import dependencies of the module.
| The default value is 0. For a list of supported flag values, see
| the LOAD_LIBRARY_SEARCH_* entries in LoadLibraryEx.
...
| [...] if you specify the link option /DEPENDENTLOADFLAG:0x800
| (the value of the flag LOAD_LIBRARY_SEARCH_SYSTEM32), then the
| module search path is limited to the %windows%\system32 directory.
The changed documentation is but STILL wrong, /DEPENDENTLOADFLAG
also FAILS to restrict the DLL search path for LOADTIME linking.
JFTR: for the definitions of RUNTIME linking and LOADTIME linking,
see <https://msdn.microsoft.com/en-us/library/ms685090.aspx>
and <https://msdn.microsoft.com/en-us/library/ms684184.aspx>
Demonstration (continued):
~~~~~~~~~~~~~~~~~~~~~~~~~~
5. build another minimal application SNAFU.EXE from the following
source file SNAFU.C
__declspec(dllimport)
extern BOOL WINAPI _DllMainCRTStartup(HANDLE hModule, DWORD dwReason, LPVOID lpReserved);
__declspec(noreturn)
VOID WINAPI mainCRTStartup(VOID)
{
ExitProcess(_DllMainCRTStartup != NULL);
}
with the following command:
CL.EXE SNAFU.C SNAFU.LIB /link /DEFAULTLIB:kernel32.lib /ENTRY:mainCRTStartup
6. run the second application SNAFU.EXE and display its exit code
with the following commands:
.\SNAFU.EXE
Echo %ERRORLEVEL%
The exit code is 0, proving that /DEPENDENTLOADFLAG:... does
NOT limit the DLL search path for Windows' module loader!
7. When you change the return value of the DLL's entry point
function _DllMainCRTStartup() to FALSE, Windows module loader
shows a message box and the exit code is 0xC0000142 alias
STATUS_DLL_INIT_FAILED, again proving that
/DEPENDENTLOADFLAG:0x800 does NOT work as documented!
8. When you erase SNAFU.DLL and run SNAFU.EXE, Windows module
loader shows a message box and the exit code is 0xC0000135
alias STATUS_DLL_NOT_FOUND, which is the expected behaviour
if /DEPENDENTLOADFLAG:0x800 would work as documented and limit
the DLL search path to %SystemRoot%\System32\
stay tuned, and don't trust unverified or incomplete documentation
Stefan Kanthak
