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: <20100911085845.GA26697@syn.titan.net>
Date: Sat, 11 Sep 2010 01:58:45 -0700
From: Fyodor <fyodor@...ecure.org>
To: Dan Kaminsky <dan@...para.com>
Cc: full-disclosure@...ts.grok.org.uk,
	Nikhil Mittal <nikhil_uitrgpv@...oo.co.in>
Subject: Re: Nmap NOT VULNERABLE to Windows DLL Hijacking
	Vulnerability

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/