miscoded

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, 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!

+=

Short status update: They've been busy at Yahoo moving accounts from Yahoo Mail Beta to Yahoo Mail 1.0 - all but one of my usual test accounts have suddenly lost the "Beta" text from the icons. Today's weekly build isn't bad either, after a couple of weeks where Y!Mail seemed to hit every crash bug in the internal builds, it's finally stabilised and runs pretty smoothly.

On Monday (or possibly even earlier) a new browser.js will go public for 9.5, and it should resolve most of the issues that currently prevent Y!Mail from loading in the new weekly build. Sorry to keep you waiting but I was working later than my server admin colleague tonight..

This time, to get Y!Mail working I had to remove several patches. Since our shiny, improved getters and setters support enables the Y!Mail compatibility layers to do their job, patching should hardly be required anymore...

Actually, the current version of browser.js messes it all up and gets in the way - several of the errors you see if you try to load Y!Mail right now is from browser.js code where the old patches are incompatible with the new getters and setters stuff!

This is great news. Removing patches is good. And I've never seen Y!Mail work better with Opera than Y!Mail 1.0 and 9.5 9594 with the new browser.js - even chat works nicely! You Yahoo mail users should have something to look forward to

Eating your own dog food is a great way to test software.

Except that the worst thing about "dogfooding" is the crap bug reports one files when there is no time to analyse because one is trying to get something else done.

This summer we were trying to book a DFDS Seaways trip. My wife complained about a server error near the end of the very long-winded booking process. Test. Reproduce. Re-test in another version. Reproduce. Re-test with HTTP traffic logging to try to investigate quickly. Give up. File half-baked bug report. Switch to IE for booking - I'VE SPENT HOURS JUST GET ME A TICKET - and see exactly the same 500 error at the same stage of booking, from a website that was obviously well and truly broken. What a vasted bug report..

Or the excuses:

"Yes, I will look up that bus schedule for you but I noticed that the menu on the bus company's web site didn't work". "Sorry that it took me so long to order the CD, I just had to check out a very strange JavaScript error message". "I'll stop using this computer right now, I just need to E-mail that travel agency about their outdated JS library".

So guys, I think each and every one of you is remarkable for actually eating our dog food by following the desktop team's blog, each weekly build being downloaded thousands of times and inspiring hundreds of comments and bug reports. Such fabulous and awesome supporters and dogfood eaters.

If you ever came across code that starts

eval(function(p,a,c,k,e,r)

here's a small demonstration of how to turn that code into something sensible..

A word of warning: I'm experimenting with Wink for creating Flash screencast-type demonstrations. That means you agree to receive a 1.5 M .swf file of screenshots and text by clicking through to the post.

I haven't quite mastered Wink, some unintentional mouse movement might occur but anything in the spirit of experimentation.. Feel free to tell me in comments whether you like more of those Flash-based visual demonstrations or prefer the old-fashioned screenshot approach.

Read more...