14 DAY TRIAL // Adobe has recently rebutted the claims of a security researcher, according to whom a design flaw in the way Flash Player executes SWF files can put websites accepting user uploads at risk. The professional now says the company totally missed the point and that its expectations of webmasters to address this are completely unrealistic.
Almost two weeks ago, we reported about the security risks of misconfigured crossdomain.xml files. These files contain rules for Flash's cross-domain access policy. However, more recently, a security researcher named Mike Bailey has exposed an ever more dangerous issue with Flash's same origin policy.
A same origin policy is a security model according to which a script being executed from a domain can only access resources on the same domain. Mr. Bailey claimed that, while this held true for JavaScript, it differed when it came to ActionScript, the scripting language of Flash. The researcher has actually identified two separate design choices the Flash developers made, which, in his opinion, are flawed and open the door for various cross-site-scripting-like attacks.
The first one is in the way Flash Player chooses to execute files or not. In order to determine if a file is a valid SWF, the player checks for its header. The header consists of a special series of bytes, also known as magic numbers, which are used to sign files. This means that it is possible to load a file as SWF, even if its extension is not .SWF, as long as it is embedded in the page as a SWF object and its magic numbers are correct.
The second problem is that a SWF file hosted on domain A and embedded into a page served from domain B is able to run ActionScript in the context of domain A and JavaScript in the context of domain B. This can be used to achieve a cross-domain interaction condition, which should not be possible under a proper Same Origin Policy.
Now, in order to actually exploit this shortcoming, an attacker would need to upload a malicious .SWF file on the domain they wish to attack. For websites that allow the upload of such files, this is straightforward. However, for others that ban the .SWF extension or perform more advance upload validation, a technique called content overloading can be used.
This trick will work with files in the ZIP family, such as ZIP archives, self-extracting executables, Microsoft Office Open XML documents, XPI files, or JAR files. The technique involves prepending a SWF file to a ZIP-family file and keeping the extension of the latter. From a server's perspective, the resulting file will be a valid ZIP file and will be served with an "application/zip" content-type to the browser.
This doesn't matter, though, because of Flash Player's previously discussed "magic numbers" method of checking the validity of embedded SWF files. "This makes it far easier to upload an object to a webserver- a Flash file can look like anything to the server and still be executable, as long as it starts with the right sequence of bytes," Bailey concludes.
Adobe rebutted the problem and claimed that there was no flaw on its part. Furthermore, it suggested that webmasters should fix this on their end by serving user uploads with the content-disposition: attachment header or to serve these uploads from a secondary domain.
The problem with the first solution is that it is not practical for all types of user-uploaded content, such as content for which it should be possible to later display it inline. The secondary domain solution is even more problematic for junior webmasters running pre-made Web applications, such as galleries, forums, blogs or even small online shops. "[...] This is not just unrealistic to expect, it's virtually impossible," the researcher notes.
Unfortunately, these are the only two solutions for webmasters that need to allow SWFs to be uploaded. For websites that don't need this functionality, there is a third solution and that is to check the magic numbers of uploaded files and ban the ones corresponding to SWF, 0x46 0x57 0x53 and 0x43 0x57 0x53, regardless of the files' extension. Either way, this is still beyond the capabilities of an inexperienced webmaster and, according to Bailey, "Any security professional will tell you that a technology that requires a blacklist approach to input validation is poorly designed."
Given Adobe's position and the architectural nature of these problems, chances are that they won't be addressed very soon. Therefore, brace yourself for possible attacks. If the proper conditions are met, all that's required for a logged-in user to have their sensitive information compromised is to visit a maliciously crafted page.