<paul.sz...@sydney.edu.au> wrote:
> Fyodor <fyo...@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/
