bugtraq - Almost no resp. only some mitigation(s) for "DLL hijacking" via load-time dependencies

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <B9FB67066EAF427AA1B75F87AEDF8F00@W340>
Date: Mon, 21 Dec 2015 12:07:44 +0100
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: <fulldisclosure@...lists.org>
Cc: <bugtraq@...urityfocus.com>
Subject: Almost no resp. only some mitigation(s) for "DLL hijacking" via load-time dependencies

Hi @ll,

in <http://seclists.org/fulldisclosure/2015/Nov/101> I showed
general mitigations for DLL hijacking via runtime dependencies
(<https://msdn.microsoft.com/en-us/library/ms685090.aspx>).

DLL hijacking is but also possible via load-time dependencies
(<https://msdn.microsoft.com/en-us/library/ms684184.aspx>)!

Example:

Quite some executable installers use the function timeGetTime()
(<https://msdn.microsoft.com/en-us/library/dd757629.aspx>)
implemented in WinMM.dll (and NO other function from WinMM.dll).

BUT WHY?

This function yields the same result as GetTickCount()
(<https://msdn.microsoft.com/en-us/library/ms724408.aspx>)
implemented in Kernel32.dll.

The notable difference: WinMM.dll is NOT in the list of "known DLLs"
(<https://support.microsoft.com/en-us/kb/164501>), 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.

TELL YOUR USERS! TELL YOUR CUSTOMERS! WARN THEM!

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!

Examples:

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