Re: DLL hijacking with Autorun on a USB drive

[Dan Kaminsky <dan () doxpara com>]

...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 () gmail 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 () doxpara 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 () larryseltzer 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 () doxpara com]
> > > Sent: Friday, August 27, 2010 10:08 AM
> > > To: Larry Seltzer
> > > Cc: Valdis.Kletnieks () vt edu; full-disclosure () lists 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 () larryseltzer 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/
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/