12.31
Yesterday, I ran across a very interesting XSS vulnerability involving
Flash embeds and Wordpress.com. The vulnerable code is now patched (even
during the holidays, Automattic’s response time was stellar), so here
are all the juicy details. 
In the interest of security, Wordpress.com limits what HTML elements its users are allowed to post on their blogs. Anyone who’s interested can read about those limits on the Wordpress.com site. However, to allow users to embed different types of content (i.e. videos, music, etc), Wordpress.com supports a series of “shortcodes.” These codes are typically created for trusted websites (i.e. YouTube) and allow users to embed content without using HTML directly.
It turns out that VodPod, one of the websites with a Wordpress.com shortcode, provides a way to embed third party content. It does so by generating a URL like http://widgets.vodpod.com/w/video_embed/ExternalVideo.12345 which 301 redirects to your content hosted elsewhere. The Wordpress.com shortcode, when parsed, becomes an embed tag using the VodPod URL. Your browser will happily follow the redirect, allowing any SWF to be displayed within a Wordpress.com blog.
Now, under normal circumstances, that wouldn’t be an issue. These days, just the act of embedding a Flash applet on your page doesn’t cause security issues. However, there was a tiny issue with the HTML that Wordpress.com generated for embeds from VodPod. I’ve reproduced the bad embed code below:
1 2 3 4 5 6 7 | <embed
src='http://widgets.vodpod.com/w/video_embed/ExternalVideo.12345'
type='application/x-shockwave-flash'
AllowScriptAccess='always'
pluginspage='http://www.macromedia.com/go/getflashplayer'
wmode='transparent'
flashvars='' width='425' height='350' />
|
The problem? The embed tag contained AllowScriptAccess='always'.
According to Adobe’s documentation, that meant the embedded SWF
could execute JavaScript in the context of the page it was being
displayed on. Coupled with the ability to embed arbitrary SWFs from
third parties, it made an XSS attack against Wordpress.com possible.
So, I shot off an email to Automattic’s security email address with the
details: I received a reply very quickly and the vulnerability was
patched (by changing the value for AllowScriptAccess to sameDomain)
within a few hours. A very happy ending to this holiday tale. 
Comments