Tag: Safari
2011
08.15

Safari for Windows handles text/plain content improperly (CVE-2010-1420)

Category: Vulnerability Writeups / Tag: Apple, content-type sniffing, Safari, security, web application security, xss / comments

Summary

Safari for Windows employed unsafe content-sniffing behavior on pages that were served up as text/plain. As a result, an attacker could cause cross-site scripting to occur in locations that would not normally be vulnerable. This issue was fixed in Safari 5.1. It has been assigned the identifier CVE-2010-1420.

How Did It Work?

When web pages were served up with a text/plain content type, Safari for Windows would determine the correct content handler by looking at their file extension. For instance, a text/plain document located at http://example.com/file.html would be parsed as HTML rather than rendered as text. In most other browsers, a text/plain content type precludes the content from ever being handled as HTML (IE being the exception).

Of course, that behavior is not very interesting by itself. Most URIs that serve up content as text/plain don’t also have HTML file extensions. However, in certain cases it’s possible to append data to the path portion of the URI without changing how the request is routed. In those cases it was possible to exploit this content-sniffing behavior by appending a filename with an HTML extension. It was also possible to cause cross-site scripting when user-controlled content was served up in this way.

The simplest example is PHP’s support for PATH_INFO. By default, most PHP installations allow arbitrary data to be appended to the path portion of the URI; the portion of the path after the file itself is stored in $_SERVER['PATH_INFO']. So, just about any PHP script that serves up content as text/plain could also be used to exploit this vulnerability.

I set up a script, located at http://sandboxing.me/poc/b82553b2869b7fa80766ec55073e998a.php, as a demonstration. The code is as follows:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
<?php header('Content-type: text/plain'); ?>
<?php header('X-Content-Type-Options: nosniff'); ?>
<html>
    <head>
            <title>Test</title>
    </head>
    <body>
            <script>alert(1);</script>
    </body>
</html>

I included the X-Content-Type-Options header for completeness, since it’s used by IE to override similar insecure content-sniffing behavior. As expected, Safari for Windows ignored the header.

To use the script for testing, I simply appended a forward slash to the URL, followed by a filename. Safari used the newly provided extension to determine how the file contents were parsed. Some examples:

HTML:
http://sandboxing.me/poc/b82553b2869b7fa80766ec55073e998a.php/test.htm
http://sandboxing.me/poc/b82553b2869b7fa80766ec55073e998a.php/test.html
http://sandboxing.me/poc/b82553b2869b7fa80766ec55073e998a.php/test.shtml
SWF:
http://sandboxing.me/poc/b82553b2869b7fa80766ec55073e998a.php/test.swf
PDF:
http://sandboxing.me/poc/b82553b2869b7fa80766ec55073e998a.php/test.pdf
EXE:
http://sandboxing.me/poc/b82553b2869b7fa80766ec55073e998a.php/test.exe
XML:
http://sandboxing.me/poc/b82553b2869b7fa80766ec55073e998a.php/test.xml
http://sandboxing.me/poc/b82553b2869b7fa80766ec55073e998a.php/test.xhtml

What about OS X?

Safari for OS X did not exhibit the same behavior: in fact, it appears that similar behavior was patched in 10.4.4 (see http://www.mnot.net/blog/2006/01/11/safari_content_sniffing).

Example Vulnerability

Bug 637981, which was recently patched in Bugzilla, relies upon this content sniffing behavior. Raw user-supplied content (in the form of an attached patch file) was being served as text/plain from the main Bugzilla domain. By uploading a malicious patch file, it was possible to cause Safari (and IE) to execute arbitrary Javascript.

Conclusion

I would like to thank Apple Product Security for handling my report and keeping me in the loop as the issue was patched. I also want to acknowledge Hidetake Jo, who discovered this vulnerability independently.