lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Mon, 21 Dec 2015 12:07:44 +0100
From: "Stefan Kanthak" <>
To: <>
Subject: [FD] Almost no resp. only some mitigation(s) for "DLL hijacking"
	via load-time dependencies

Hi @ll,

in <> I showed
general mitigations for DLL hijacking via runtime dependencies

DLL hijacking is but also possible via load-time dependencies


Quite some executable installers use the function timeGetTime()
implemented in WinMM.dll (and NO other function from WinMM.dll).


This function yields the same result as GetTickCount()
implemented in Kernel32.dll.

The notable difference: WinMM.dll is NOT in the list of "known DLLs"
(<>), so EVERY program
which uses timeGetTime() from WinMM.dll instead of GetTickCount()
will load a rogue WinMM.dll which exports timeGetTime from its
application directory.

This means: such programs are vulnerable to DLL hijacking unless
run from SAFE locations like %ProgramFiles% or %SystemRoot% where
unprivileged users can't place a rogue WinMM.dll etc. in the
programs application directory.

More general: if an executable installer links to functions not
provided by "known DLLs" for all supported versions of Windows it is
vulnerable to DLL hijacking via load-time dependencies, and there is
NO mitigation except to run it from a safe location!

Now that's a typical "catch 22": an installers task is to write the
files of an application safely, i.e. without the possibility of
tampering, to safe locations, i.e. %ProgramFiles% and %SystemRoot%,
while the installer itself is located somewhere else, typically in
a user's "Downloads" or %TEMP% directory, which are but unsafe and
allow tampering via DLL hijacking.


Or (better!): reduce your programs dependencies, i.e. stick to
the basics^Wfunctions provided by Kernel32.dll (and the other
"known DLLs") and eliminate the attack vectors for DLL hijacking
via WinMM.dll and other "unknown DLLs".

If you don't or can't: see above and WARN ALL YOUR USERS/CUSTOMERS!

JFTR: the list of "known DLLs" varies with different Windows versions!


1. Version.dll was one of the "known DLLs" of Windows NT 5.x (resp.
   still is in Windows Embedded POSReady 2009): the (many) executable
   installers linked to its functions were/are therefore not
   vulnerable in Windows NT 5.x resp. Windows Embedded POSReady 2009.

   In newer versions of Windows Version.dll is none of the "known DLLs",
   so all executable installers using its functions became vulnerable
   to DLL hijacking then.

2. SetupAPI.dll is none of the "known DLLs" in Windows NT 5.x, but
   became so in newer versions of Windows: the (many) executable
   installers linked to its functions were/are vulnerable unter Windows
   NT 5.x resp. Windows Embedded POSReady 2009, but ain't vulnerable
   any more in all newer versions of Windows.

Conclusion: executable installers which link to "unknown DLLs" are in
general unsafe for normal users.

The only SAFE option for general use is: DUMP executable installers.

stay tuned
Stefan Kanthak

Sent through the Full Disclosure mailing list
Web Archives & RSS:

Powered by blists - more mailing lists