Page MenuHomePhabricator

Revisit mangleFlashPolicy()
Closed, ResolvedPublic

Description

The vulnerability

OutputHandler::mangleFlashPolicy() was introduced in 2007 in response to a reported security issue. I can't find the report right now, but it went something like this:

  • The Flash client may specify any URL on a host to act as a cross-domain policy file. For example, an action=raw view may be used as a cross-domain policy.
  • Despite being specified as an XML file, Flash does not actually use an XML parser, but rather runs some regexes over the response, looking for relevant XML-like tags. So XML inside JSON, HTML, CSS, etc. can potentially be interpreted as a valid policy.
  • If the response thus contains permission for Flash to execute a cross-domain request, the Flash client may read CSRF tokens and thus execute a CSRF attack against any page on the domain.
  • The Flash browser extension does all these requests by calling back into the browser, thus they are sent with the cookies of the currently logged-in user, and a generic browser User-Agent header.

So the result is that if the application sends anything vaguely looking like a cross-domain policy file from any URL, the result is a CSRF vulnerability against anything on the domain that uses cookie authentication.

The problem

mangleFlashPolicy() is intrusive, complex, and it's unclear if it's necessary. If it's necessary, it's unclear if it's a complete fix.

Prospects

The first question is whether we still need to worry about this, given the demise of Flash. The current documentation notes that cross-domain policy files are also respected by Adobe Acrobat and potentially other products. So, maybe. And I assume people are still using Flash one way or another.

The current specification, published in 2009, states that a response may send the header X-Permitted-Cross-Domain-Policies: none-this-response in order to prevent the response from being interpreted as cross-domain policy. We could send that on every request, or only on requests where the response matches a regex.

Unless we simply drop security support for browsers with flash installed, any change will need to be tested. I'm not sure how to do that.

Event Timeline

Apart from browsers and OSes having put Flash behind feature flags, behind click-to-run barries and/or unshipped entirely (or all three in the case of Safari, you install it on your own, and then still click-to-run afaik).

Apart from that, according to Adobe's end of life statement one of their releases a year ago or so basically installer a timer that will make the plugin unrunnable after a certain date. Which means even existing installs that are somewhat up to date will no longer be active, I think.

But I suppose someone might have a copy predating that "EOL will come" time bomb. And there's third-party implementations used e.g. for archived copies on Internet Archive and such. I don't know how those fare in terms of security, however.

But I suppose someone might have a copy predating that "EOL will come" time bomb.

If less than 0.1% of clients have a working flash installation, then I think we can drop security support.

And there's third-party implementations used e.g. for archived copies on Internet Archive and such. I don't know how those fare in terms of security, however.

IA uses Ruffle, which is Rust compiled to WebAssembly. That's fine for security because WebAssembly cannot bypass the browser's cross-origin content rules.

Ruffle is also provided as a native browser extension, so I suppose that should be reviewed for security.

I grepped the Ruffle source and found no implementation of cross-domain policy. I found a couple of complaints in the Ruffle bug tracker about it not supporting crossdomain.xml. The response from the devs is "use CORS".

So it's probably fine.

Apart from that, according to Adobe's end of life statement one of their releases a year ago or so basically installer a timer that will make the plugin unrunnable after a certain date. Which means even existing installs that are somewhat up to date will no longer be active, I think.

[Two links for entertainment:] That's also my understanding, so some organizations seem to have downgraded their systems to an older Flash version or even created their own web browser for download to allow their clients to file out their tax revenue forms.

Change 815827 had a related patch set uploaded (by Tim Starling; author: Tim Starling):

[mediawiki/core@master] Remove Flash cross-domain policy mangling

https://gerrit.wikimedia.org/r/815827

Change 815827 merged by jenkins-bot:

[mediawiki/core@master] Remove Flash cross-domain policy mangling

https://gerrit.wikimedia.org/r/815827

tstarling claimed this task.