Date: Fri, 27 Aug 2010 10:14:40 -0400
From: Larry Seltzer <larry@...ryseltzer.com>
To: Dan Kaminsky <dan@...para.com>
Cc: full-disclosure@...ts.grok.org.uk, Valdis.Kletnieks@...edu
Subject: Re: DLL hijacking with Autorun on a USB drive

#1 in the DLL search list is the directory from which the program was
loaded. How can you have a scenario where CWD is a better choice than that?
Why would it be a good choice DLL sharing?



Here’s another possibility for a Microsoft action. Add a search location 1.5
specified by the application to Windows. If all the Office apps are sharing
DLLs they can put their apps in Office/sharedDLLs and point to it. At least
we could move forward from here. Microsoft’s choice here dooms us to this
problem for the forseeable future.



*From:* Dan Kaminsky [mailto:dan@...para.com]
*Sent:* Friday, August 27, 2010 10:08 AM
*To:* Larry Seltzer
*Cc:* Valdis.Kletnieks@...edu; full-disclosure@...ts.grok.org.uk
*Subject:* Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive



h0h0h0.  There be history, Larry.

Short version:  Go see how many DLLs exist outside of c:\windows\system32.
Look, ye mighty, and despair when you realize all those apps would be broken
by CWD DLL blocking.

Longer version:

Unix has always had the tradition of a system administrator.  When it went
consumer, it went straight to package management -- something it could do,
because a) there just aren't that many apps and b) they're mostly open
source, so distros can legally fix things up.

Windows comes from a different direction:  Many, many consumer facing apps,
very few of them open source, users installing for themselves, no package
manager.  Among other things, this introduces the concept of:

Which DLLs should you load?

Suppose you have ten applications, each using foo.dll.  Should they all use
foo.dll from c:\windows\system32?  Maybe, maybe not.  There are many
possible versions that might be in there, and they might or might not work.

You can push your version of foo.dll into c:\windows\system32.  Great,
you'll work fine, but there's nine other apps you might break.

You can use a local foo.dll.  Now you can have your lib and they can have
theirs.

Welcome to DLL hell.

There's been a lot of work in fixing this situation, but not from the
security perspective.  I know we're masters of righteous indignation, but I
have to emphasize -- while there's probably an actual vuln somewhere using
this methodology, nothing's been found yet.  Changing something with only a
tenuous link to security, with such a massive impact on whether applications
run or not?  Yeah, not exactly surprised it's still there.

 On Fri, Aug 27, 2010 at 7:20 AM, Larry Seltzer <larry@...ryseltzer.com>
wrote:

Clearly desktops need to be able to run arbitrary code. That’s what they’re
there for.



Why wouldn’t eliminating the CWD from the DLL search order fix the problem?
I asked Microsoft about this (
http://blogs.pcmag.com/securitywatch/2010/08/list_of_dll_vulnerability_wind.php)
and they said the obvious answer, that it would break too many customer
installations. And I guess it would break a bunch of them, but there really
isn’t a good reason for anyone to load a DLL from the CWD, is there?



I think they dropped the ball on this at Vista time. They made so many other
changes for security reasons then that forced users and developers to change
practice that this one wouldn’t have been such a big stink. And they’ve
known about the basic problem for 10 years (and should have known earlier,
since it was a UNIX attack beforehand).

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/

Powered by blists - more mailing lists