Re: Nmap NOT VULNERABLE to Windows DLL HijackingVulnerability

["Stefan Kanthak" <stefan.kanthak () nexgo de>]

<paul.szabo () sydney edu au> wrote:

> Fyodor <fyodor () insecure org> 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]
  @=expand:"%ProgramFiles%\<vendor>\<product>\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

  "Path"="...[;...]"

  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
     <http://support.microsoft.com/kb/269049/en-us> alias
     <http://www.microsoft.com/technet/security/bulletin/MS00-052.mspx>

     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:

     [HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon]
     "UserInit"=expand:"%SystemRoot%\\SYSTEM32\\USERINIT.EXE"

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


Stefan

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/