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.
"UPDATE: Mr. Kanthak has told Softpedia that "most of the companies/vendors I contacted patched their products." Rapid7 went so far as to withdrew their ScanNow product altogether.
"Some of the companies/vendors which did not reply to my reports in the first place contacted me after they became aware of the [public disclosure] posts and fixed their installers, or are working on a fix now," Mr. Kanthak also added.
Additionally, there also some other software products for which Mr. Kanthak has not yet posted a public disclosure post, but to which he reported vulnerabilities, and the companies are now working on a fix."
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
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!
An LGPL program can be linked statically to a proprietary program so long as the proprietary program's publisher makes available to its licensees a set of working .o files that can be linked to a new version of the LGPL program.
I think the complaint is that the LD_LIBRARY_PATH equivalent is doing questionable things given the conventions of the target platform.
It's hard to say as there's zero details in the article and I don't have time to research what I don't really care about that much.
XML is like violence. If it doesn't solve the problem, use more.
I have asked my Hyderabad team to investigate this problem and they have reported back to me that JDBC is a fix for it.
Can anyone confirm if JDBC is a fix for this DLL problem?
How would a Java database connectivity layer fix this if it's a problem with a C++ program interacting with a C++ DLL?
Start learning security issues early on!
Sounds to me after all of Slashdot's articles that many software teams don't have a coding security expert or security team or we wouldn't have all these flaws.
absolutely it can, it's usually just a question of setting the right flags in your IDE.. In these days of laptops with 16 gigs of RAM, it's the way to go for most things.
More than tens of software products are vulnerable to key loggers installed in keyboard cables. More than tens of software products are vulnerable to compromise when executed from compromised systems.
Come on people fix your vulnerable software or we will publically slut shame you for your indifference.
You have that backwards... the article you linked says it is enabled for all apps by default. Calling SetDllDirectory DISABLES Safe DLL Loading and causes the problem!
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.
Am I alone in thinking that if malicious code has admin level write access to system disks then you're already fubar?
The horse is gone! Shut the barn door!
XML is a known as a key material required to create SMD: Software of Mass Destruction
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.
This is slashdot. Unless you are being sarcastic about a click-baity site that we need to laugh at, "Simple Bug" is not a valid replacement for "DLL Hijacking" or, more descriptively, "DLL Side Loading" or "DLL replacement."
You want to know what will make Slashdot better? Good headlines is a fantastic start. :-)
Is it just my observation, or are there way too many stupid people in the world?
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.
You would "hard code" using system variables like this:
%CSIDL_PROGRAM_FILESX86%\Avast\Sanner\foo.dll
That would end up being "the right place" no matter which drive letter has your Program Files directory. It wouldn't load hacker\foo.dll from any location.
I know this is offtopic, but why the use of the word "tens" in the the summary? Perhaps it's a regional thing (western US here) but the term "dozens" seems much more natural to me. Unless you're talking about the very narrow range of 20-23 items i can't think of a good reason why "tens" would be preferred.
This Space Intentionally Left Blank
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.
The problem is the practice of requiring admin privileges to install most software. Software should not require admin install unless they really need it. Common frameworks (which are a big user of DLLs) do exacerbate the problem since they often want to be installed in a root location so all the applications can share it.
A solution is to forbid third parties from bundling installers for common framework runtime binaries. If the framework is needed, then either install the binaries in the application directory or tell the user to go install it themself.
Guys! I discovered a new vulnerability in Windows:
If you replace an executable with a different executable and then execute it, you actually execute the new executable and not the executable you replaced. Where should I submit my paper for publication?
I like shitting on Windows apps as much as the next guy, but if you can replace a library on the drive, aren't you just going to like... win? Maybe there's more protection on real systems, but it's a binary that gets run with the permissions and privileges of whatever is running it. Can someone explain to me how this is a larger concern, and what was done to patch the security of this?
It stands to reason that if you can overwrite a dll, you can overwrite a lot of stuff, same as with an .so or something. Is it something where in Windows its easy to overwrite the DLL in the first place?
That's a lot of name-dropping. Wonder if said researcher asked for a bit of hush money and if you paid up you were taken off the list? Smear campaigns for cash are hardly new.
So as a user you downloaded a suspect binary but it's the OS that's at fault?
It's certainly true that Windows sucks for this kind of issue, and always has, but there's only so much you can do to protect idiot users from themselves.
XML is a known as a key material required to create SMD: Software of Mass Destruction
> So as a user you downloaded a suspect binary but it's the OS that's at fault?
Yes, it's a security flaw in the OS. I should be able to download fdisk.exe (as an unprivileged user) without the OS running fdisk.exe /wipe c: (as admin). Downloading as a user shouldn't mean executing as admin.
There is a similar variable for "this program's installation directory", I believe. Generally, though, your DLLs should go where DLLs belong. Fighting against the design of the OS tends in increase the risk of a security exposure, in general.