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?

[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?

[lesincompetent]

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

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