Message-ID: <AANLkTimV48LBjLRNPkWKZ1dbE=ObAveqjFidm0N8c1eX@mail.gmail.com>
Date: Fri, 27 Aug 2010 10:50:24 -0400
From: Dan Kaminsky <dan@...para.com>
To: Christian Sciberras <uuf6429@...il.com>
Cc: Valdis.Kletnieks@...edu, full-disclosure@...ts.grok.org.uk
Subject: Re: DLL hijacking with Autorun on a USB drive

...up till the moment you realize that the interface doesn't really
differentiate between "2010 Quarterly Projections" as an .exe or as a .ppt.
Double clicking in desktop = do whatever it takes to run this, code
execution or not.

On Fri, Aug 27, 2010 at 10:36 AM, Christian Sciberras <uuf6429@...il.com>wrote:

> "....while there's probably an actual vuln somewhere using this
> methodology, nothing's been found yet"
>
>
> Do you really think so?
>
> Having any kind of executable load the first ntoskernel.dll it finds,
> such as the innocent one in it's own directory isn't really wise...
>
>
>
>
>
>
> On Fri, Aug 27, 2010 at 4:19 PM, Dan Kaminsky <dan@...para.com> wrote:
> > 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).
> >>
> >>
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> > Hosted and sponsored by Secunia - http://secunia.com/
> >
>

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