Same-origin policy: How did Adobe Flash Player's implementation fail?

A newly discovered security-feature bypass in Adobe's Flash Player allows a local attacker to spy on victims through their device's built-in microphone and camera. The bug bypasses browser protections like the same-origin policy, which is supposed to stop permissions being granted to one domain from being accessed by another domain. How did this happen, and why didn't the browser security features prevent it?

Bug hunter Paulos Yibelo discovered the security bypass vulnerability in Adobe Flash Player's implementation of the same-origin policy. Tracked as CVE-2016-7890, it has a CVSS v3 base score of 9.8, placing its severity rating as critical. Flash Player versions 23.0.0.207 and earlier, as well as 11.2.202.644 and earlier, are all vulnerable. The vulnerability is easy to exploit, as an attacker doesn't require special privileges or authentication, so it's essential that administrators install the necessary patches to mitigate the attack.

The same-origin policy security mechanism plays a vital role in the web application security model, as it restricts web content in one domain from interacting with resources from another domain. The same-origin policy ensures the protocol, port and host exactly match before resources from one domain can access resources from another.

For instance, a browser will allow the page at https://www.example.com to access the document object model (DOM) of a document retrieved from https://myaccount.example.com, but not the DOM from a document retrieved from https://www.example.es or http://www.example.com, as the host name is different in the first case, and the protocol and port are different in the second. This enables users to visit different sites without them being able to interfere with their sessions from other sites. If it isn't enforced, a script could read, use or forward data hosted on any webpage, including cookies and session data.

Although Flash Player's default security model enforces the same-origin policy, it can make exceptions if a website hosts a cross-domain policy file -- an XML document called crossdomain.xml, which specifies how data on a domain can be accessed by a Flash application hosted on a remote domain. Servers in a domain specified in a crossdomain.xml file can read any resource on the server where the policy file resides.

The vulnerability Yibelo discovered allows a local attacker to hijack permissions granted to other Flash applets because the Flash Player fails to implement the same-origin policy correctly. For example, if a user grants a Flash Player hosted at https://www.example.com permission to access their device's microphone and camera to participate in a video chat, that permission can be exploited by a Flash applet hosted on http://www.example.com. Flash will incorrectly see any access attempt from http://www.example.com as a request from a domain to which the user has granted access -- in this case, https://www.example.com. While this bug is only exploitable if an attacker has access to the local system, it would allow a malicious actor to gain easy access to a device's microphone or camera.

This flaw was fixed with the release of version 24.0.0.186. Apart from installing all the relevant updates and patches, including Microsoft's critical security update for Adobe Flash Player, administrators should consider preventing Flash Player from running through Group Policy if it is deemed too high a security risk.

The better, long-term solution is to remove the application completely wherever possible. HTML5 has functionality to match and even exceed Flash's capabilities, and web designers should implement multimedia content using HTML5 instead of Flash to avoid putting users at risk. Web administrators should review the configuration of any crossdomain.xml files to ensure they only grant permissions to specific, trusted domains and remove them if there is no longer a business requirement for Flash to communicate with the website.