Chrome the improper use of Flash message loop leads to the UXSS Vulnerability, CVE-2016-1631)

ID SSV:92545
Type seebug
Reporter Root
Modified 2016-11-21T00:00:00


Author: Avfisher@network sharp knife

0x00 Preface

This writing comes from a few days ago a buddy sent me a bug link to let the author help explain the vulnerability principle, in order to facilitate the partner understanding and left notes for future reference and then write this article.

This article discusses the vulnerability has been already fixed, but as vulnerability research is still very valuable. This vulnerability by researchers Marius Mlynski discovered and, 2015 12 month 14 report of a Chrome improper use of Flash message loop to produce the UXSS Vulnerability, CVE-2016-1631 on.

0x01 analysis

Vulnerability impact:

Chrome 47.0.2526.80 (Stable) Chrome 48.0.2564.41 (Beta) Chrome 49.0.2587.3 (Dev) Chromium 49.0.2591.0 + Pepper Flash

The original bug report is as follows: ``c From /content/renderer/pepper/ppb_flash_message_loop_impl. cc:

int32_t PPB_Flash_MessageLoop_Impl::InternalRun( const RunFromHostProxyCallback& callback) { (...) // It is possible that the PPB_Flash_MessageLoop_Impl object has been // destroyed when the nested message loop exits. scoped_refptrstate_protector(state_); { base::MessageLoop::ScopedNestableTaskAllower allow( base::MessageLoop::current()); base::MessageLoop::current()->Run(); } (...) }


The reporter explained: PPB_Flash_MessageLoop_Impl::InternalRun in running a nested message loop until not initialized ScopedPageLoadDeferrer, which leads to be able to in any Javascrpit to perform point load a cross-domain document cause the XSS to.

Next, we look at the report provided by the POC, there are three main files:

  • p. as: an ActionScript script file
  • p. swf: a swf format Flash file
  • poc.html: specific poc code

``javascript p. as:

package { import flash. display.; import flash. external.; import flash. printing.*; public class p extends Sprite { public function f():void { new PrintJob(). start(); } public function p():void { ExternalInterface. addCallback('f', f); ExternalInterface. call('top. cp'); } } } ``

``javascript poc.html:


POC works in a page to create multiple sources for the Flash file to the iframe, and then call as the script to open the print tasks, at this time Chrome will by PPB_Flash_MessageLoop_Impl::InternalRun method in the main thread to run a nested MessageLoop-message loop to send PPB_Flash_MessageLoop message to the renderer, since PPB_Flash_MessageLoop_Impl::InternalRun method is not on the stack set ScopedPageLoadDeferrer to postpone the loading of resulting in a nested MessageLoop in the loop when the callback script and load any resources as a result of the UXSS vulnerability.

How, then, to understand this vulnerability?

In Chrome, we know that each thread has a MessageLoop(message loop instance. Report of the PPB_Flash_MessageLoop_Impl is actually Chrome process Flash event to the message loop implementation. When the browser receives to print a Flash file to the message, it will open a MessageLoop to process the print event, but this time if you are running a nested message loop does not terminate the script callback and the resource loading method, you can pass a script callback code to bypass the SOP to load any resources, it will cause a XSS vulnerability.

From the following is the source code author to do the repair can better understand the vulnerability of the generated reasons.

Not difficult to find, the source the author actually only made the following changes:

1. Added#include “third_party/WebKit/public/web/WebView. h”;

2. In the implementation of base::MessageLoop::current()->Run();before add a blink::WebView::willEnterModalLoop();

3. In the implementation of base::MessageLoop::current()->Run();after adding a blink::WebView::didExitModalLoop();

Find third_party/WebKit/public/web/WebView. h file, we find a step 2 and Method 3 are as follows:

``c third_party/WebKit/public/web/WebView. h:

// Modal dialog support------------------------------------------------
// Call these methods before and after running a nested, modal event loop
// to suspend the script callbacks and resource loads.
BLINK_EXPORT static void willEnterModalLoop();
BLINK_EXPORT static void didExitModalLoop();



Obviously, fix the vulnerability is in the implementation of a nested modal event through the bad before and after calling these 2 methods to prevent the script callback and the resource to the load, thereby preventing the because the script callback and bypass the SOP of the XSS vulnerability.

0x02 use

First, download the exploit and deploy to your web server.

After extracting, the documents directory is as follows: ├── exploit │ ├── exploit.html │ ├── f.html │ ├── p. as │ └── p. swf Open exploit. html modified as follows:

``javascript ```

The use of effect is as follows:

0x03 reference

Original link: