full-disclosure - Re: DLL hijacking with Autorun on a USB drive

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 for Android: free password hash cracker in your pocket

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

Date: Fri, 27 Aug 2010 10:08:08 -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

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/