full-disclosure - Re: Nmap NOT VULNERABLE to Windows DLL Hijacking Vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTimBnA_e2KWEiPk+Sk2DXxAu586=Qr7NXk7gTzJw@mail.gmail.com>
Date: Sat, 11 Sep 2010 18:32:31 +0530
From: jai <jaikumar.shinde@...il.com>
To: Fyodor <fyodor@...ecure.org>
Cc: full-disclosure@...ts.grok.org.uk,
	Nikhil Mittal <nikhil_uitrgpv@...oo.co.in>
Subject: Re: Nmap NOT VULNERABLE to Windows DLL Hijacking
	Vulnerability

Dear Fyodor,


NMAP is detected by Snort and othr IDS, is not possible to have fool proof


~j.


On 9/11/10, Fyodor <fyodor@...ecure.org> wrote:
>
> On Fri, Sep 10, 2010 at 02:08:14PM -0400, Dan Kaminsky wrote:
> >
> > Frankly, I think we can find better bugs.  I think we'd better.  Just
> > like bad money drives out good money, bad bugs drive out good bugs.
> > The credibility of advisories, and even the usefulness of FD, is
> > somewhat at risk.
>
> Hi Dan.  You make good points, like usual.  I just want to comment on
> one aspect:
>
> > So we're on the cusp of some huge portion of advisories coming from
> > the security community being little more than "random Windows app
> > runs DLLs from CWD".
>
> Another problem with this is that it is the way Windows was
> intentionally designed and documented to operate :/.  Apps like Nmap
> don't know where (for example) Winpcap's DLLs are installed on a given
> system, so we rely on the operating system to locate and load them
> securely.  Most operating systems do this properly, and it isn't very
> hard.  You just need a library search path which only contains system
> directories that potential attackers can't write to.
>
> Microsoft, on the other hand, intentionally decided to include the
> current working directory in that search path.  Up until XP SP2, they
> even gave DLLs in CWD priority over those in system directories!  Then
> MS introduced "SafeDllSearchMode", which is now enabled by default.
> This SHOULD HAVE removed CWD from the library search path entirely,
> but instead Microsoft just shifted the search order around so that CWD
> is searched later :(.
>
> Now Microsoft has added a new hack, calling SetDllDirectory() with the
> empty string, which actually DOES remove CWD from the search path if
> you are running a recent enough version of Windows.  But many/most
> apps won't even know to call that.  The search path should be secure
> by default (especially when things like "SafeDllSearchMode" are set),
> and apps or users should have to add CWD themselves if they really
> want it included.
>
> So rather than have advisories for every application which honors the
> default Windows DLL search path, I hope someone can convince MS to
> make their search path secure by default (remove potentially untrusted
> dirs like CWD).  Linux/Unix users would have the same vulnerabilities
> if they did something dumb like add CWD to their LD_LIBRARY_PATH, but
> at least their vendors don't ship it that way!
>
> And while anyone is bugging MS about the DLL search path, please ask
> MS to re-enable raw sockets too :).
>
> Cheers,
> Fyodor
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

Content of type "text/html" skipped

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