> > 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. > > The "easy demo" is with clicks, which needs registration of extensions. > 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.
Correct me if I am wrong, but my understanding of the issue was not the default library search path, but rather that people are using SearchPath() or similar to locate DLLs which they then pass to LoadLibrary(); thus making it not a default behavior, but one from people who didn't read the API docs. This isn't really relevant to nmap and whether its 'vulnerable' or not; I can't see anyone opening a URL with nmap itself, so it seems fairly irrelevant to me. Just commenting on whether this is default behavior or not. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
