Message-ID: <e0fb669dd6ec4a1089f3e1f7ec2575e8@mail.gmail.com>
Date: Fri, 27 Aug 2010 15:03:42 -0400
From: Larry Seltzer <larry@...ryseltzer.com>
To: Arthur Orr <aorr@....com>, Dan Kaminsky <dan@...para.com>, 
	Christian Sciberras <uuf6429@...il.com>
Cc: full-disclosure@...ts.grok.org.uk, Valdis.Kletnieks@...edu
Subject: Re: DLL hijacking with Autorun on a USB drive

You have a point. If you’re using a whitelisting system and are strict about
it then you should not be vulnerable.



This made me think of another issue: I just checked PowerPoint 2007, one of
the apps listed as vulnerable, and both the EXEs and DLLs are digitally
signed. Shouldn’t it be inherently suspicious for a signed program to load a
DLL it expects to be signed but which isn’t? I know the extensibility
argument would explain this, but honestly, there’s no good reason to replace
most of the DLLs in Office. This is another check that could be put into
LoadLibrary I guess: confirm that signatures are consistent with the EXE.



*From:* Arthur Orr [mailto:aorr@....com]
*Sent:* Friday, August 27, 2010 1:52 PM
*To:* Larry Seltzer; Dan Kaminsky; Christian Sciberras
*Cc:* full-disclosure@...ts.grok.org.uk; Valdis.Kletnieks@...edu
*Subject:* RE: [Full-disclosure] DLL hijacking with Autorun on a USB drive



I’m not sure that I agree that there is nothing that antimalware systems can
do to mitigate the risk.



What about white-listing solutions in lock-down mode such as Lumension’s or
Bit9’s or Symantec’s or…well you get the idea.  If the DLL is not trusted
(not known) it won’t run until it is trusted.  The downside is the lack of
something similar for the average Jane or Joe in the average home.  A few
come close but the average Jane or Joe is probably going to click right past
prompts anyway.



This is not to say that white listing is easy, just that it is a mitigating
defense.



*From:* full-disclosure-bounces@...ts.grok.org.uk [mailto:
full-disclosure-bounces@...ts.grok.org.uk] *On Behalf Of *Larry Seltzer
*Sent:* Friday, August 27, 2010 8:59 AM
*To:* Dan Kaminsky; Christian Sciberras
*Cc:* full-disclosure@...ts.grok.org.uk; Valdis.Kletnieks@...edu
*Subject:* Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive



I will admit that I don’t have a **good** solution to this. It bothers me
that there’s no systemic solution coming for so widespread a problem.



I’ll add some more depressing news: there’s basically nothing that
anti-malware or IPS systems can do about this that they aren’t already
doing, i.e. scanning the DLLs before they load. Often with vulnerabilities
there’s a lot they can do, even if they’re not a perfect solution, at least
to look for specific attack code. There’s nothing about the DLL loading
technique that looks malicious.



*From:* Dan Kaminsky [mailto:dan@...para.com]
*Sent:* Friday, August 27, 2010 10:50 AM
*To:* Christian Sciberras
*Cc:* Larry Seltzer; full-disclosure@...ts.grok.org.uk;
Valdis.Kletnieks@...edu
*Subject:* Re: [Full-disclosure] 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