Re: DLL hijacking with Autorun on a USB drive

[Dan Kaminsky <dan () doxpara com>]

On Thu, Aug 26, 2010 at 3:53 PM, matt <matt () attackvector org> wrote:

> Hey guys..
>
> Here's an example the DLL hijacking attack using a USB drive with autorun.
>  I haven't seen this done yet, so I figured I'd post it.
>
> http://www.attackvector.org/autorun-dll-hijacker-usb-stick/
Sure, but you have the same problem most of the other DLL hijacking exploits
have:

There's no security boundary that says that what appears to be a .ppt,
actually is one.  The attacker controls both the icon and the filename.
That's the case from a network share, that's the case from a USB mount,
that's just the way it is.

Here's the larger picture:

These are unusually interesting findings.  On the one hand, you have
arbitrary code execution, generally the gold standard for vulnerability.  On
the other hand, operating systems *by definition* execute arbitrary code
The question is whether they're supposed to execute code in this particular
context.

The answer is not actually obvious.

The specific boundary at play seems to be the document boundary.  There are
very popular file formats that we'd like to be able to read and view,
without running any embedded code inside -- powerpoint files, for instance.
In the proposed scenario, the user has double clicked a file from a remote
share.

Calc pops up.  Clearly a vuln, right?

Here's the problem:  How could this boundary ever be maintained?  The user
has no actual way of knowing that the file he's clicking on is, in fact, a
PowerPoint document in the first place.  It could just as easily be a .exe,
faking its icon.  And every major operating system has been hiding file
extensions for years.

Worse, even if extension weren't hidden, its not like applications have any
sort of "safety contract" when executed from the desktop.  Some formats have
very clear mandates, inherited from being trafficked via email.  Others are
outright scripting languages and are fundamentally designed to execute
arbitrary code.

The web has developed a very clear security model:  If you can parse it zero
click from a web site, it's required to stay within the browser sandbox.
The desktop has no such model -- some formats are 'safe', others aren't.

There was some talk about whether PSD was "vulnerable" to this flaw.  The
complexity comes from the fact that, for all we know, opening a PSD file
executes arbitrary scripts by design.  Why shouldn't it?  Not everything is
a web browser.

So, it's not that this is a weak bug or a massive bug.  It's a
characteristic, that has managed to make the otherwise unambiguous proof of
concept -- popping calc -- ambiguously problematic.  That's actually
impressive, if a bit meta.

We'll probably see some unambiguous attacks pop up, but they haven't yet.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/