14 DAY TRIAL // Security researchers revealed that EXE files are vulnerable to the same type of remote binary planting attacks, which can be used to load rogue DLLs.
According to Microsoft, binary planting or DLL hijacking bugs are the result of insecure programming practices and occur when applications try to load external libraries without specifying their exact location.
Failback mechanisms for various DLL loading functions involve Windows searching for a file in a series of predefined folders if the full path to it is not supplied.
One of these locations is the "current working directory," which in many cases can be a network share or even a remote WebDAV resource.
This "working directory" is pretty low on the list of places Windows inspects, which means this issue can pretty much be exploited only if the file is missing from the system.
Unfortunately, it seems that hundreds of applications, including very popular ones, attempt to load inexistent DLL files for some reason or another.
And now there's even more bad news, as researchers from ACROS Security found that the programming interfaces used to create new processes can be tricked in a similar way.
In fact, launching rogue EXEs can be even easier than loading rogue DLLs and the guidelines previously issued by Microsoft to developers don't help in this case.
It seems that for some widely used functions like CreateProcess*, WinExec or LoadModule the current working directory is the second search path, while for ShellExecute*, _spawn*p* and _exec*p* it is actually the first.
An example of how this can be exploited was described in an ACROS advisory regarding a vulnerability patched a few days ago in Safari.
Each time a HTML document was being opened in Safari with the file:// handler the browser called explorer.exe (Windows Explorer) without specifying its exact location.
Because of the insecure search path, placing a rogue explorer.exe inside the same directory as the .html file (the working directory) lead to it being executed before the legit one.