Slashdot Mirror
Researcher Finds Tens of Software Products Vulnerable To Simple Bug (softpedia.com)
An anonymous reader writes: There's a German security researcher that is arduously testing the installers of tens of software products to see which of them are vulnerable to basic DLL hijacking. Surprisingly, many companies are ignoring his reports. Until now, only Oracle seems to have addressed this problem in Java and VirtualBox. Here's a short (probably incomplete) list of applications that he found vulnerable to this attack: Firefox, Google Chrome, Adobe Reader, 7Zip, WinRAR, OpenOffice, VLC Media Player, Nmap, Python, TrueCrypt, and Apple iTunes. Mr. Kanthak also seems to have paid special attention to antivirus software installers. Here are some of the security products he discovered vulnerable to DLL hijacking: ZoneAlarm, Emsisoft Anti-Malware, Trend Micro, ESET NOD32, Avira, Panda Security, McAfee Security, Microsoft Security Essentials, Bitdefender, Rapid7's ScanNowUPnP, Kaspersky, and F-Secure.
The obvious question is; what's a DLL?
"The likes of Facebook and WhatsApp are free to those whose privacy is of zero value."
There's an informative (and non-PDF) post on Fortinet's blog discussing DLL hijacking. You can use a registry tweak to harden a system against this technique.
I'm aware of the Windows DLL load behavior, and how it creates "DLL Hell." I never thought of the security implications, because I assumed that Windows behaved more ... sanely.
The root of the problem is that the affected applications are installers, which need to be run with elevated rights. On Linux systems, for example, when an application is run with escalated rights (through SUID or sudo), the dynamic library loader uses only the system library paths and ignores user specified paths (such as the LD_LIBRARY_PATH environment variable).
Why the HELL doesn't Windows do the same for apps run as administrator?
DOZENS!
I don't know how code signing verification policy works on Windows, but on OS X, Gatekeeper checks only an app's main executable for a signature against an Apple-issued code signing certificate, not other executables in the same folder that it loads.
Actually, you only have to insert it into the current working directory. For example: Get a dll file downloaded into Downloads, then wait for the user to run Setup.exe and have UAC hand it admin privileges. Now your non-privileged process has put a DLL file in the Downloads directory *with* Setup.exe, which loaded Downloads\CommDlg32.dll and was granted Administrator access. Now you have admin access.
Microsoft Word used to do this if you had a DLL file with the same name as a System32 DLL in the same path as a Word document.
Support my political activism on Patreon.
In this case it would be up to the installer to verify that it is loading a valid library. The problem is if somehow a certain named and versioned dll can be downloaded to the same folder you execute the installer from it can execute arbitrary code when the installer initializes it using the elevated privileges you granted the installer.
So in order to implement this side-loading you would to first need take advantage of another vulnerability to get that library in the right place.
In order to protect against this they could simply not include the execution folder in the search path and validate the library in a manner other than just the name and version which can be faked.
If someone where to try and exploit this chances are they would attempt to run their code in the background while leaving the rest of the library untouched so the installer would complete without tipping off the user. This means something as simple as a file size could validate there wasn't a bunch of extra code present, although there are better methods for validating a library.
That would make sense but there are two things to consider. First, you may be using a different compiler or even language all together for a dll versus your main application. Second, there are legal implications with OSS licenses when it comes to dynamic versus static linking.
It does leave you permanently vulnerable to any flaws in the particular version of the library you linked against, or such is my understanding. At least with dynamic linking you can blame the user for not keeping up to date!
I still static link though because whenever I upload something (using a video filtering plugin) at least one person won't have the right runtime installed at all.
systemd is Roko's Basilisk.
MSDN is saying, by default, "Safe DLL" loading is used, in which the current directory is only used if loading the DLL from most other locations failed. So this would not be viable any more. It sounds like this problem was identified and fixed long ago. Any attempt to exploit this now would require gaining greater access first, and once you're there there's no point to using DLL hijacking any more.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx
It isn't a problem, and the installer need take no special measures. The system's loader restricts the search path for dynamic libraries when it's running with elevated privileges so you don't accidentally run an infected library in some random location (for example, the download directory).
There are also techniques available to load libraries from a specific path after the program starts rather than at load time. You can use that to choose a specific full path to the exact library you want to load and it still counts as dynamic linking.
It does leave you permanently vulnerable to any flaws in the particular version of the library you linked against, or such is my understanding.
The assumption being that anyone (for most definitions of anyone) knows what DLLs their application loads and what the status of their patch levels are.
I still static link though because whenever I upload something (using a video filtering plugin) at least one person won't have the right runtime installed at all.
Which IMHO is the main mitigating factor -- what's the actual security risk versus the functional risk of the wrong library breaking the program?
I don't know if its technically possible, but it would be interesting to use a computer where everything was statically linked to see how much worse resource usage really was.
If you have the ability to write a malicious DLL into a folder for the executable, you already have the ability to run administrator level code. Why bother with the DLL?
cf: Raymond Chen
Exactly. Raymond covered this a few times in the past.
Using delayload to detect functionality is a security vulnerability
It rather involved being on the other side of this airtight hatchway: Disabling Safe DLL searching
If Safe DLL Search Mode is enabled, then the Current Directory isn't searched until after all the system directories are searched. Safe DLL search mode is enabled by default starting with Windows XP with Service Pack 2 (SP2).
This sounds like a complete non-story.
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
I'm going to simplify this a bit, but consider you download two things songlist.zip. You extract songlist.zip, which is a data. You don't execute anything in that download. You just extract it to your downloads folder and use notepad to open the resulting songlist.txt. You don't notice that it also included a file called netssl.ddl, which sits in your downloads folder.
Later, you download mcafee_setup.exe. You run macafee_setup.exe, which needs to run as admin. mcafee_setup.exe makes use of netssl.dll. It could use the hacked version which was part of songlist,zip, running code with full admin privileges that you never intended to run at all.
This doesn't seem like a very big vulnerability because it still requires the user to explicitly trust an installer to install executable code. Whether that code is an executable or a DLL that gets loaded into another application, once you've installed malicious software, you're screwed.