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 -

Relevant Pages

  • Issue #89
    ... FileBoss for Windows ... Program Homepage/Download url ... In general users make a program execute at window startup by ... Adding programs to the Registry and WIN.INI file protects the program. ...
  • Re: Windows XP home login/off
    ... How to Perform an In-Place Upgrade of Windows XP ... Click on How To Run a Repair Install ... registry has worked the 5 or 6 times I have seen this problem. ... The script will stop and ask you to hit enter to continue to load SCSI ...
  • RE: Windows 2000 RRAS and ipSEC /L2TP VPN
    ... How to Configure a L2TP/IPSec Connection Using Pre-shared Key Authentication ... This article contains information about modifying the registry. ... , Windows 2000 is compliant with IKE RFC ...
  • RE: Networking and DOS attacks
    ... Windows has found 55 Critical System Errors... ... Install Repair Registry Pro. ... I have tracked all of these UDP port hits since 2001. ...
  • Re: OT: Win 7 comments
    ... I had to edit the Registry. ... This is right up there with repairing permissions, ... That's odd, consider how some of you guys bring the same habits to Windows, ... I will wait for some apps to crash. ...