Understanding the Rosetta Flash vulnerability
Rosetta is a new way to create Flash files, which made possible a new kind of vulnerability affecting many websites, including very popular ones.
LinkedIn then returns the JSONP-formatted data by calling Malicious() (in the context of the malicious page).
Malicious() can only read the information that LinkedIn sends: it can’t modify information and it can’t control what is sent. This explains why JSONP requests are commonly used, even if it could look an information leak: when implemented correctly, it’s not a security risk in itself, because external websites can’t control the information that is sent. But if a Flash file was passed as a callback parameter instead of a function like Malicious(), it could have more control, because it could be executed by the browser in the context of the target site (and if you’re wondering why, that’s just because that’s how Flash works). To prevent that, JSONP requests only accepts printable characters in callback parameters
._0123456789 abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ
Enters the Rosetta Flash vulnerability, known as CVE-2014-4671. With complex tricks, it’s actually possible to make a Flash file made only of printable characters. By using such a Flash file as a callback parameter, the Flash file is executed by the browser, in LinkedIn’s context: this gives control to the malicious website over the LinkedIn page’s information. It affected many major websites:
LinkedIn, eBay, Google, Instagram, Twitter, YouTube, Baidu, Tumblr, Flickr, Yahoo! …
A simple way to prevent this for a website is to prepend a comment (such as /**/) at the start of the callback parameter: this will prevent the callback parameter to be interpreted as Flash, as Flash files are not allowed to start with comment characters, even with Rosetta.