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.
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.
Dynamic linked library
Dynamic Link Library. Typically a shared resource that can be dynamically loaded and unloaded when needed, and often shared among programs.
The problem with DLLs are that there are many versions of the same DLL that often need to run at the same time. Which means that you can substitute one version for another, and hijack a program. Nothing new here.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
Dynamic-link library (also written unhyphenated), or DLL, is Microsoft's implementation of the shared library concept in the Microsoft Windows and OS/2 operating systems. These libraries usually have the file extension DLL, OCX (for libraries containing ActiveX controls), or DRV (for legacy system drivers). The file formats for DLLs are the same as for Windows EXE files – that is, Portable Executable (PE) for 32-bit and 64-bit Windows, and New Executable (NE) for 16-bit Windows. As with EXEs, DLLs can contain code, data, and resources, in any combination.
https://en.wikipedia.org/wiki/Dynamic-link_library
Nothing new, because it is how Windows was designed from the early days.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
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.
Although it is very true that it is how windows was designed from the early days, modern versions of windows do have protections against loading DLLs from network locations that applications simply have to opt in to. For those that are designed to be locally installed to have NOT adopted those defenses is just like not bothering to enable ASLR (Address Space Layout Randomization), or other security measures. These applications should be updated to use the protections. Here's info on how to make the updates to applications: https://msdn.microsoft.com/lib...
MSDN documents guidelines for preventing malicious DLL loading. Windows has already cut off "current directory" forms of attacks by changing the DLL load order (called "Safe DLL Search Mode" in that document), and with Vista locking down Program Files for admin-only access, "application directory" attacks are also out unless apps intentionally install themselves elsewhere (then they're on their own). As for installers, users have to get tricked into downloading the DLL first, and at least Chrome gives you a big warning that the file is suspicious due to its extension. And if you can get the user to do that, you might as well just give them an EXE and skip the warning. It's easier to put together a malicious EXE too.
Dynamic Link Library or Shared Object. In the early days of UNIX, it was found that the huge amount of space was being used by GUI applications and command line programs statically linked to common libraries like standard IO, sockets, X-windows, GUI's, maths and crypto libraries. Huge amounts of disk space were being used to stored duplicate copies of compiled code. So they figured that it would be more cost effective to dynamically link at run-time instead of a compile-time with the bonus that they could be compiled into relocatable code only loaded into system when needed.
If you run "ldd" on a program, you will see all the libraries needed for that program.
By separating the library files from the applications, any bugs or problems could be fixed through a simple upgrade. The downside is that someone can rootkit a system by replacing a DLL used by applications that need system access.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
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
/)
There is no "bug" with the installers or windows, the machine has been compromised prior to running the software.
TFA is a "beat up" (likely paid for by Oracle), it does not explain how the attacker is able to put the compromised dll on the machine in the first place. If an attacker can put a random binary on your local drive then they already own your machine. What a random installer subsequently does on a compromised machine is irrelevant to how the machine was hacked.
Car analogy: If a miscreant cuts your brake line without your knowledge, it is not the manufacturer's fault that the brakes no longer work as advertised. If the manufacturer's can make it more difficult to cut the brake line that's great, but they cannot, and should not, be held accountable for malicious damage caused by someone who had unrestricted access to your brake line.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
Literally the FIRST hit on Google leads to this:
https://en.wikipedia.org/wiki/...
tl;dr - it's not really a problem to force an arbitrary process to load a DLL, *if you are an administrator*. As noted elsewhere though, if you have the power to inject, you already owned the machine, so why bother?