Re: [Full-disclosure] Nmap NOT VULNERABLE to Windows DLL HijackingVulnerability
- From: "Stefan Kanthak" <stefan.kanthak@xxxxxxxx>
- Date: Mon, 13 Sep 2010 22:52:18 +0200
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
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
Fortunately, it was MSFT too who advised their customers to open
this hole: see <http://support.microsoft.com/kb/249321/en-us>
MSFT but could have done it right in the first place with:
This works with NT4 and Windows 2000. In later versions, some
braindead developer but removed the expansion of environment
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/
- Prev by Date: [Full-disclosure] [SECURITY] [DSA 2108-1] New cvsnt package fixes arbitrary code execution
- Next by Date: [Full-disclosure] [ MDVSA-2010:181 ] ntop
- Previous by thread: Re: [Full-disclosure] Nmap NOT VULNERABLE to Windows DLL Hijacking Vulnerability
- Next by thread: [Full-disclosure] [SECURITY] [DSA-2103-1] New smbind packages fix sql injection