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

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?

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

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.