Discussion:
Nmap NOT VULNERABLE to Windows DLL Hijacking Vulnerability
(too old to reply)
p***@sydney.edu.au
2010-09-09 01:29:17 UTC
Permalink
... 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() ...
And, people loading DLLs they do not need, for OS version detection.
(Maybe others?)
... I can't see anyone opening a URL with nmap itself ...
An "exploit scenario" for nmap: send a ZIP (or somesuch) archive to
the victim, containing a data file and a "hidden" DLL, with message:
Hey, these seem infected with conficker, check with nmap
and the victim using "nmap -iL datafile" from current dir.

Cheers, Paul

Paul Szabo ***@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
V***@vt.edu
2010-09-10 16:07:13 UTC
Permalink
Inability to recognize a straight forward vulnerability = mentally handicap
I'll bite - I don't use nmap on Windows platforms. Anybody got an actual
*plausible* way to actually abuse *somebody else's* system with the alleged
nmap vuln? Sure, you can easily shoot yourself in the foot with the DLL issue -
but how do you get somebody else to shoot themselves in their foot for your
benefit?
Dan Kaminsky
2010-09-10 18:08:14 UTC
Permalink
On Fri, Sep 10, 2010 at 11:46 AM, Nikhil Mittal
Here's my definition
Exploitable vulnerability = vulnerabilityn't t
Non-exploitable "vulnerability" = mental masturbation
Nice definition. I would like to add one more line for my definition
Inability to recognize a straight forward vulnerability = mentally handicap
OK, lets go over this again.

Nikhil, Simple DLL Hijacking is quite possibly the least
straightforward potentially exploitable condition *of all time*.  We
may look back on this characteristic as the thing that finally proved
the legitimacy of Cross Site Scripting attacks -- compared to Simple
DLL Hijacking, XSS is practically a stack smash.  Simple DLL
Hijacking's problem is as follows:

a) The presumed preconditions for an attack are extensive and expensive
b) An attacker who met those preconditions, would not be stopped by
the proposed defenses

Regarding a, we're seeing lots of PDF 0-day floating around.  Why?
Because it's pretty cheap to get somebody to parse a PDF:  <iframe
src='foo.pdf'> and you're done. Getting someone to go through all the
steps with SDH? Too complicated.

That being said, there are scenarios. Matt @ AttackVector probably
found the best one right now -- a worm drops DLLs into a shared
document folder, and anyone who opens the docs gets hit. And of
course, multiple people have figured out that SDH causes problems for
Autorun defenses, because a document read (not copied) directly off a
thumbdrive will presently launch code.

Even if you grant these are legitimate vectors, these are vectors
bouncing off Office's presumed type safety -- not WinImageView
3.4.8's. And they're not even close to straightforward.

The core problem though is that Explorer itself doesn't strongly
enforce type safety. I can't emphasize enough, you just don't have
enough context when you double click an item in a browser, that it's
not actually an .exe. People keep pretending you do have this
context, and it's simply untrue. Look at it this way: If it was as
easy to execute arbitrary code from a web page, as it was from a
Explorer Shell Window to \\attacker.com\foo, we'd be up in arms.

So essentially, what you find is that the very concept of browsing
remote shares and USB sticks you don't trust, is unsafe. This creates
the astonishing situation where Sharepoint becomes a security
technology!

You might notice that I keep referring to all this as Simple DLL
Hijacking. It's likely that DLL Hijacking will actually be a critical
component of a genuine attack vector. It's just not, yet. The
journey of a thousand miles has been declared complete with a single
step. 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".

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.

--Dan

P.S. Maybe there should be a new list -- full-disclosure-sdh -- for
this discussion? I can't be the only one wondering how enormous this
thread has to get. Yeah, yeah, I know. I'm dreaming.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Fyodor
2010-09-11 08:58:45 UTC
Permalink
Post by Dan Kaminsky
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
Post by Dan Kaminsky
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/
YGN Ethical Hacker Group
2010-09-11 17:12:11 UTC
Permalink
A lot of black hats will intentionally launch a whole mess of
nmap and nessus scans from zillions of throw-away zombies, just so their *real*
attack can fly under the wire.
Totally agree.
Intrusion attempts, port scanning, ..etc takes place all the time in
Internet space. Who really cares?
Tools such as - idswakeup - inundator - ownsnort have been round for a while.

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

Loading...