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.

Comments

DLL Hijacking

[Anonymous Coward]

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.

Re:What's a DLL?

[Anonymous Coward]

Dynamic linked library

Re:What's a DLL?

[Archangel Michael]

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.

Re:What's a DLL?

[Anonymous Coward]

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

Re:What's a DLL?

[lesincompetent]

The obvious questions are:
- Why are you here?
- Why the semicolon?

Re:What's a DLL?

[Archangel Michael]

Nothing new, because it is how Windows was designed from the early days.

Why is this a flaw in the app, and not the OS?

[MSG]

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?

Re:Why is this a flaw in the app, and not the OS?

[The MAZZTer]

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.

Re:Why is this a flaw in the app, and not the OS?

[StormReaver]

...because I assumed that Windows behaved more ... sanely.

After all these years, why the hell would you think that?

Re:Why is this a flaw in the app, and not the OS?

[scdeimos]

Any directory in the DLL search path for a normal application installed in a normal location is only writable by an (elevated) administrator user. If you can drop a random DLL file into such a folder you've already got administrator rights on the machine, so why make things any more complicated?

You've obviously never heard of ClickOnce then. ClickOnce deployment technology, available since .NET Framework 2.0, allows a signed application and its related DLLs to be downloaded into a folder within the user's own AppData folder structure and executed from there. It doesn't require Administrator rights to do this because it's within the user's own AppData folder structure. Just because an application is signed doesn't make it trustworthy.

There are literally dozens of them...

[Anonymous Coward]

DOZENS!

Re:What's a DLL?

[jones_supa]

It's a shared object for a toy computer.

Are you suggesting that Windows makes a toy computer? Wouldn't a toy GUI consist mostly of big colored squares, dumbed down applications, and a supervisor monitoring your usage patterns?

Re:Other side of the airtight hatchway

[bluefoxlucid]

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.

Re:What's a DLL?

[GIL_Dude]

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...

Re:Other side of the airtight hatchway

[pr0fessor]

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.

 

Re:What's a DLL?

[mikael]

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.

Re:Other side of the airtight hatchway

[nmb3000]

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.

Re:What's a DLL?

[TapeCutter]

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.

Re:What's a DLL?

[mhotchin]

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?

Re:What's a DLL?

[TapeCutter]

It's no longer a problem with MS libraries but it can still be a problem with third party dll's, the problem is not that different to having symlinks point to multiple versions of an .so file in unix. In both cases it works when done correctly, but it's easy to get the wires crossed if you're not careful.