Message-ID: <AANLkTin=kyyXzpEz70Lfz7ZbcKuW7S5Brc3Ho-x00Jv5@mail.gmail.com>
Date: Fri, 27 Aug 2010 10:19:29 -0400
From: Dan Kaminsky <dan@...para.com>
To: Larry Seltzer <larry@...ryseltzer.com>
Cc: full-disclosure@...ts.grok.org.uk, Valdis.Kletnieks@...edu
Subject: Re: DLL hijacking with Autorun on a USB drive

Well, if I pull out the crystal ball, I see two possibilities:

1) Patch goes out, implementing this policy
2) 1% of customers go dark
3) That's a WHOLE BUNCH OF CUSTOMERS WHO DISABLE WINDOWS UPDATE

1) Patch goes out, off by default
2) 0% of customers turn it on
3) That's a MEANINGLESS REGISTRY ENTRY THAT COST A BUNCH OF MONEY TO WRITE

Neither look exactly appetizing, and it's not like we (yet) have a clear
vulnerability that needs to be addressed.

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

>  #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