The vulnerable system is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers). An example of a network attack is an attacker causing a denial of service by sending a specially crafted TCP packet across a wide area network (e.g., CVE-2004-0230).
Attack Complexity
Low
AC
The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
Privileges Required
Low
PR
The attacker requires privileges that provide basic capabilities that are typically limited to settings and resources owned by a single low-privileged user. Alternatively, an attacker with Low privileges has the ability to access only non-sensitive resources.
Scope
Unchanged
S
An exploited vulnerability can only affect resources managed by the same security authority. In the case of a vulnerability in a virtualized environment, an exploited vulnerability in one guest instance would not affect neighboring guest instances.
Confidentiality
High
C
There is total information disclosure, resulting in all data on the system being revealed to the attacker, or there is a possibility of the attacker gaining control over confidential data.
Integrity
High
I
There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the attacker being able to modify any file on the target system.
Availability
High
A
There is a total shutdown of the affected resource. The attacker can deny access to the system or data, potentially causing significant loss to the organization.
Below is a copy: Microsoft Windows 10 DLL Search Path
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
This information is provided for TESTING and LEGAL RESEARCH purposes only. All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use and Privacy Policy and Impressum