Re: [Full-disclosure] Nmap NOT VULNERABLE to Windows DLL HijackingVulnerability

<paul.szabo@xxxxxxxxxxxxx> wrote:

Fyodor <fyodor@xxxxxxxxxxxx> wrote:

nmap <= 5.21 is vulnerable to Windows DLL Hijacking Vulnerability.

Nmap is not vulnerable. DLL hijacking works because of an unfortunate
interaction between apps which register Windows file extensions and
the default Windows DLL search path used for those apps. Nmap does
not, and never has, registered any Windows file extensions. So it
isn't vulnerable to this issue.

I beg to differ: nmap is of course vulnerable, it may load airpcap.dll
from CWD due to the well-known deficiency in Windows' LoadLibrary().
The question but is: how (easy) can this be exploited.

The "easy demo" is with clicks, which needs registration of extensions.

... and to lure the unsuspecting user.

The "real thing" is a DLL in the current directory. Unless you always
use "cd path/to/nmap; ./nmap" to start, you are vulnerable: most people
would set their %PATH% to include the right thing for easy nmap.

Are you kidding?
The normal Windows user will almost never use the command line, for most
of them "cd path/to/nmap; ./nmap" is just gibberish (yes, some users will
use Explorer and perform the GUI equivalent of these commands.-)
The same holds for setting/changing the PATH.

The right thing^W^WWindows way for "easy nmap" is:

* for a GUI/mouse user: create/use a shortcut (*.LNK) in the start menu
or on the desktop during installation.

When an application is started from this shortcut, CWD will be set to
the path specified as "Run in:" in the *.LNK, if given there. If but
omitted/left blank, CWD will be set to the directory which was CWD
when the shell was started.

* for a CLI/keyboard user: create the registry entry

[HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\application.exe]

during installation.
This allows a "start application" in the command interpreter, as well
as Start->Run "application" [Enter] in the shell/on the desktop.

Additionally you can add a registry entry


which gets prepended before %PATH% when "application.exe" is started,
in every way described above!

It's the task of the developer/packager of "application.exe" to create
the correct shortcut and to create the right registry entries for his
"application.exe" to prevent havoc!

BTW: MSFT got bitten by the search path a LOOONG time ago: see
<> alias

Fortunately, it was MSFT too who advised their customers to open
this hole: see <>

MSFT but could have done it right in the first place with:

[HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon]

This works with NT4 and Windows 2000. In later versions, some
braindead developer but removed the expansion of environment
variables there.


Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -