Home > Security > Regarding DLL Hijacking

Regarding DLL Hijacking

Been recovering some old writings that never got posted.  Back in August, we were talking  a lot on Full Disclosure about DLL hijacking.  The question of what represents a bug, is actually more complex than people realize, so I weighed in.  I’m responding to Matt from AttackVector.org, and he’s just posted another attack, this one an AutoRun variant.

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.

They still haven’t, though I don’t expect this state to last forever.

Categories: Security
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: