A malicious thought: how to imagine a security issue

So Dan Kaminsky claims on Wired that the browser is the bug after investigating Flash security policy issues. Well, we already know that the Flash security policy is too liberal by default, and it's not exactly a bug in the browser from my point of view –

But the Wired article is interesting, though not very detailed. Some scope for imagination.. so let's imagine he has found a way the page will "spoof" its own address to confuse the plugin when it tries to apply samedomain policies.

Just imagine, how might that happen?

One of the unbelievable shortcomings of the old Netscape plugin API is that it doesn't actually tell the plugin the address of the page you're loading. That makes it kind of hard for a plugin like Flash to apply any meaningful samedomain security policy!

What Flash does to work around this is to ask the browser to open this URL:

javascript:window.location+"__flashplugin_unique__"

and read the output. In other words, to spoof the address of the page you're at would require making the browser see another object than the real window.location in this request. (Also, it means Flash can't apply security policies when JavaScript is disabled.. And I wonder if IDNA allows underscores in URLs now and what would happen if Flash ran on, say, http://www.example.com__flashplugin_unique__.com? Will Flash see their "unique" string and consider it the end of the URL?)

Of course we can not set "location" because trying to set it will take you away from the page and destroy the plugin instance you're trying to confuse.

Is there any other way to hide the location object?

The malicious thought: elements with IDs populate the global object (aka window). What would happen if we added an element with the id "location" to the document? Something like..

<div id="location" href="http://www.example.com/"></div>

just might make the browser see something completely different if you read window.location.href …

Here is a
test case.
Luckily for your online safety Opera, Firefox, IE7 and Safari on Windows all pass – so move on, nothing to see here. But it's a good test case to keep around – for next time we tweak how elements are exposed in the global scope – and perhaps it inspires more of you to look for those places where feature + feature = security issue..

For security testing, every malicious thought is welcome!

:devil:+:sherlock:=:wizard:

Advertisements

3 thoughts on “A malicious thought: how to imagine a security issue

  1. Hmmm… window.location.prototype? Temporarily replace the location object with a different object?I don't like prototype.js and this is exactly why. Don't know if it works, though, but since the location object plays such an important part I doubt many will have tried to hack it, let alone test its predisposition to be hacked.

  2. Good try 🙂 Though in Opera at least neither location nor window has a .prototype object. I guess they don't inherit from Object either..Another angle might be

    delete window.location

    but it seems .location sensibly is marked dontDelete.

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