When a new thing occurs or is invented, or when a previously obscure thing becomes popular, a need emerges to give it a name so we can talk and write about it. It was no different with binary planting, DLL hijacking, DLL preloading, insecure library loading, DLL load hijacking and DLL spoofing. Except that, unfortunately, these different names all describe essentially the same thing - an attack* against a Windows application where this application loads a malicious executable instead of some intended legitimate one. We get asked a lot why we choose to use the term binary planting, so here's our reasoning.
One major reason for us to dislike words "DLL" or "library" in the name is that this problem affects not only dynamic-link libraries but also other types of executables. Furthermore, "DLL" sounds as if the insecurely loaded library always has a ".dll" extension - which is not the case, as our research has found applications trying to load libraries with extensions ".ocx", ".nls", ".tbp" and many other funny extensions. We chose to use the noun binary, which covers all types of executables involved in these vulnerabilities. So why not simply use executable? Executable is too long a word and would probably quickly be shortened to "EXE," causing a similar misunderstanding we already have with "DLL."
As for other shortcomings of the alternative terms:
- DLL hijacking implies that either a DLL gets hijacked or something gets hijacked using a DLL. But in large majority of binary planting vulnerabilities the binary (for instance, a DLL) in question does not exist - that is, until the attacker plants it. You can't hijack something that doesn't exist. One could say that a vulnerable application gets hijacked through a malicious DLL but then every vulnerability could be called hijacking of some sort. Note, however, that before Windows XP SP2, the dynamic-link libraries search order had the current working directory in the 2nd place, which produced a lot of possibilities to actually hijack an existing DLL (e.g., one from the Windows system folder) by placing a malicious copy with the same name in the current working directory. Back then, hijacking would have sounded more suitable.
- DLL preloading implies that some presumably malicious DLL gets loaded in advance (of something). We find no such advance-loading process taking place in the context of this vulnerability.
- Insecure (library) loading sounds accurate as long as it's only libraries one considers. When other executables (EXEs or COMs, for example) join the party, loading is not a very suitable term any more. While technically, these also get loaded before they're executed, it's more common - and more understandable - to say they get ran, started, executed or launched.
- DLL load hijacking is a little better than DLL hijacking as it implies that it is the process of loading that gets hijacked (and used for malicious purposes). However, this term contains an unfortunate hard-to-pronounce triple-L, and is likely to quickly (d)evolve into DLL hijacking. And again - just like with insecure library loading -, loading is not a very suitable term for non-library executables (EXEs, COMs, etc.).
- DLL spoofing is actually a nice term, short and accurate, but has long been widely used for another similar but conceptually very different activity, namely manually replacing an existing DLL on one's own computer in order to change the behavior of an application or operating system. This activity has nothing to do with security, at least not in terms of one person (attacker) doing something bad to another person (user), since the user does it to himself, so to speak.
We chose the verb planting because, in our opinion, it accurately describes what the attacker needs to do in order to carry out the attack: planting a malicious binary somewhere where a vulnerable application will pick it up and execute it.
So these are our reasons for preferring the term binary planting to other alternatives for describing the entire scope of the problem. As it currently seems, DLL hijacking (for describing an attack) and insecure library loading (for describing a vulnerability) are here to stay as well, at least for libraries. This will certainly continue to cause unneeded confusion but perhaps a vulnerability class that has been overlooked for such a long time deserves more than one name.
(* Strictly speaking, the term insecure library loading does not describe an attack, but a vulnerability.)