Date: Tue, 31 Aug 2010 11:12:42 -0400
From: Charles Morris <cmorris@...odu.edu>
To: matt <matt@...ackvector.org>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: DLL hijacking with Autorun on a USB drive

On Fri, Aug 27, 2010 at 11:27 AM, matt <matt@...ackvector.org> wrote:
> Dan,
> While I agree with most of what you're saying, I do find this to be a pretty
> serious issue, and here's why.
> 1) The file doesn't have to be fake.  It could be a legitimately real ppt,
> vcf, eml, html, whatever.  The program(s) load the rogue DLL file and there
> doesn't seem to be any major impact on the functionality of the software,
> meaning that the end user wouldn't know that there was something hostile
> taking place.  The file opens, they can view it, modify it, whatever, and
> all the features seem to work.  Perception is reality.
> 2) This opens the door for more widespread attacks.  In the case of
> PowerPoint, one could simply find a share on a network that contains a large
> amount of ppt files and save his/her rogue DLL file in that directory.
>  Then, whenever anyone opens one of the files, the attacker gets immediate
> access to the victims PC without the victim having any idea.
> 3) People are getting smarter and do view .exe's as threats.  Yes, because
> of the fact that extensions are usually hidden and that you can modify the
> icon to be whatever you want it to, it's trivial to trick an end user into
> clicking on just about anything.  However.. if I pass out my Power Point
> presentation on a USB stick at a business meeting that has legitimate
> content, no one is going to have any clue that anything else took place.
>  There's also very little risk of detection, because you don't have to worry
> about that one user who doesn't have extensions hidden, or someone noticing
> that the icon looks funny, or different.  It simply makes for a more
> stealthy attack.
> To be honest, the whole DLL hijacking concept reminds me a lot of the old
> temp race "vulnerabilities" from back in the day.  Is it really a
> "vulnerability" in the true sense of the word?  Not really.. it's taking
> advantage of a series of events and being first to cross the finish line.
>  But, I believe that because we can get the system to execute arbitrary code
> (OUR arbitrary code), this really does present a serious problem, just like
> the old temp race conditions did.
> Anyway, I appreciate the feedback.. and yes, ultimately I agree that
> invoking this through Autorun is probably, for the most part, useless, but I
> was asked if it was possible and I honestly wasn't sure that it would be,
> which is why I wrote the post after I found out that it was.
> - matt
> www.attackvector.org
>
>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

I'm going to be honest here, I see this whole "DLL Hijacking" thing as
a non-issue. It's a known behavior. Don't run applications from
untrusted locations- because then you can't trust the application- not
just the DLLs it loads.

We aren't in the UNIX world here, yes windows may have fine-grained
permissions but with the bubbly/stupid GUI from Vista onward.. I'm not
even sure how to use them off-hand- so I know for a fact
random-user-sixpack can't do it. You can't just casually glance at a
file on a random network share and know that nobody has been
manipulating it; and it's stupid to think otherwise.

Do you run random executables from flashdrives you find on the floor?
Even if it has a solitaire icon? No.

If there was a setuid root executable that gave you a nice game of
solitaire over X, while running any script at /tmp/runme.dll^H^H^Hsh -
would you call this a vulnerability or a horrible design choice?
Especially so when it's -clearly- documented that it runs said script?

And yes, the first thing to do on a windows desktop is to disable
crappy menu fades, UAC, and "hide extensions";
along with a slew of other garbage. I normally spend two hours in MMC
as soon as it's up. It's time for others to do the same.

If you want to "fix" this, you may of course implement signed DLLs,
but then you get the issue of signed DLLs. It would just turn out to
be another UAC or MS-Maintained "SSL Authority List".

I suppose it would be nice if an application would compare a checksum
of a DLL to a hardcoded value before it loaded it, but then you get
the issue of newer (but fully compatible) DLL versions having
different checksums, etc, etc. It's just a mess caused by stupid
design by Microsoft.

Now, if there was a way to move a CWD of a more-privileged-user
process to a less-privileged-adversary defined directory before
loading a given DLL, that would be a real vulnerability.

> the old
> temp race "vulnerabilities" from back in the day.  Is it really a
> "vulnerability" in the true sense of the word?  Not really..

Oh, and, race conditions are real vulnerabilities. There is no
question/argument on this.

Cheers,
Charles

_______________________________________________
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