CVE-2015-3096 - Rosetta Flash fix bypass using UTF-8

Rosetta Flash meets UTF-8 ... CVE-2015-3096

1. You may know Rosetta Flash attack (CVE-2014-4671) that uses JSONP callback to echo back flash payload and execute the flash -> CSRF attack on vulnerable sites - which were (almost?) all JSONP-enabled sites at that time.
   
   
2. The original Adobe's fix wasn't good enough and Adobe released another fix ... CVE-2014-5333
   
   
3. Yesterday (June 09, 2015) Adobe released another patch APSB15-11 with a fix of this new CVE-2015-3096

TL;DR: Adobe fix for Rosetta Flash expected only ASCII payload => let's send a 2-bytes UTF-8 character => protection bypass ... flash loaded => CSRF / information theft.

Intro

The core idea of Rosetta Flash vulnerability is to convince a victim site to echo back a payload sent in request. The response can use whatever content-type, the payload just must be the first thing written into the response.

Then all we need is to send a flash file as the payload. Browser loads the file like it would be hosted on the victim site and runs the flash payload, with the victim site origin policies.

JSONP enabled services are the perfect target, they write the payload (JSONP callback) as the first thing in the response.

Browser recognizes the payload as a valid flash file, run the flash with the victim site origin policy so the flash can steal data or perform CSRF there.

Attack Design

Michele Spagnuolo invested into the research and described the vulnerability in the most devastating way - using only ASCII characters for the flash file payload which was correct for most/all JSONP endpoints.

Adobe fixed it accordingly - expected only ASCII coming from the victim server. When the victim site returns a non-ASCII character in the first 4096 bytes, Flash Player assumes it's a safe scenario and executes the flash.

But, living in Unicode world, there are also sites supporting UTF-8 characters in JSONP callbacks.

Now, all we need is to create a valid flash file with a non-ASCII byte => 2-bytes UTF-8 character with first byte being always >= c0 (hex).

----

I used RosettaFlash github project to encode flash files using ASCII + one higher UTF-8 character at the end - https://github.com/topolik/rosettaflash/compare/master...utf8checksum

Example flash file (URL encoded), please note the 2-byte UTF-8 character (%df%a2 ... U+7e2) almost in the end:

CWSMIKI0hCD0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7iiudIbEAt

... content omitted for brevity ...
oooooooooooooooooooooooooooooo888888888880%df%a2%30%68

Flash Player finds the %df non-ACII byte, loads the flash file assuming it's a valid file hosted on the victim site and run the flash.

----

You can try a PoC to see if your browser+flash is vulnerable:

• http://topolik.cz/jsonp_flash_callback/ and slowly click on buttons 1, 2, and then 3, :)
• Your browser is vulnerable when you find anything catched into the log
• For more info open browser dev console -> network and look for HTTP POST request to log.php

Mitigation on clients - update your flash:
* Linux: 11.2.202.466
* Mac: 18.0.0.161
* Windows: 18.0.0.160

Mitigation on servers - protect JSONP endpoints as described by Miki

Timeline:
* 06. 02. 2015 - Discovered and notified Adobe
* 09. 06. 2015 - Adobe released a fixed