Survey: "MIME/Content-Type-Sniffing" Issues in Image Uploads in Forum Scripts Author: Jacques Copeau Abstract ==================================================== Internet Explorer, especially versions 7 and 6, can be tricked to treat images as html, opening XSS vulnerabilities in software that allows uploads. IN a survey, we found myBB, fluxBB, phorum, SMF and WBB to be vulnerable to such attacks. I Introduction ==================================================== Mime or Content Type sniffing[1] is a standard functionality in browsers to find an appropriate way to render data where the HTTP headers sent by the server are either inconclusive or missing. Especially the Internet Explorer browser is known to use this technique even in cases where the server sends a specific content type header[2]. Internet explorer resorts to mime sniffing when either the Content-Type header and the "magic" signature at the beginning contradict or when the Content-Type header is unknown. In that case, IE will try to establish the content type and can be tricked into assuming text/html by placing certain HTML tags within the first 255 bytes of the file. Note that such files can be valid image files despite their HTML payload. A frequent example for unknown content-types is "image/bmp", which is created by PHP's (< 5.3.0) getimagesize API function[4]. This is - the obvious XSS issue aside - used for phishing attachs[3]. As file -- especially image -- uploads are a standard feature in forum scripts, we took the opportunity to survey popular forum script, whose vendors claim to be security conscious, regarding their handling of file uploads with regard to handling mime sniffing. We surveyed MyBB (1.4.5), SMF (1.1.18 / 2.0RC1), phpBB (2.0.23/3.0.4), FluxBB (1.3), phorum (5.2.10), WBB (lite/3.0.8) and vBulletin (3.8.2). Of the surveyed scripts, only phpBB and vBulletin had sufficient safeguards against attacks using mime sniffing in place. All other scripts were found to be vulnerable. We consider it to be remarkable that a suprisingly big number of scripts had no guards against a relatively well-known attack vector. However, it enabled us to directly compare the reactions of different vendors to a very similar issues. In II, we will present our findings of the survey; in III we detail the reactions of the different vendors and in IV offer our conclusions. II Survey ==================================================== 1 Methodology ____________________________________________________ For our analysis we used popular and well known PHP forum scripts with file uploading functions. We did not survey scripts like bbPress and Vanilla, which require plugins for file uploading. In Open Source scripts, we analysed the code to find out about the safeguards in place; the closed source scripts vB and WBB* were not analysed on the source-code level. We notified all vendors on April 30th. Vendors, who had not replied, were notified again on May 7th with a clear note about our intention to publish the results after four weeks. We tested for content type sniffing vulnerabilities with six different files: -A valid BMP with html/javascript in the palette (1) -A valid BMP with obfuscated html/javascript in the palette (2) -A valid PNG with html/javascript in a comment -- with an extension ".jpg". (3) -- with an extension ".gif". (4) -A valid png with obfuscated html/javascript in a comment and a .gif extension (5) -An invalid gif with javascript and a .gif extension (6) The files with obfuscated javascript were used to test the strength of filters employed by some forum scripts. We checked for three established kinds of defense against malicious uploads that exploit IE mime sniffing: - Rejecting files with patterns triggering sniffing text/html(blacklisting) - Setting correct headers to avoid sniffing from happening (validating) - remaking files with GD or IM (sanitizing) *WBB lite was analysed; we believe that the "full" WBB shares the same mechanism. 2 Detailed Descriptions ____________________________________________________ MyBB relied on setting headers and forced the download of files (i.e. content-disposition: attachment). This is a sufficient safeguard for IE7, but IE6 has the added complexity that it ignores the content-disposition, when the file is already cached. This can happen when the user cancels the download dialog and then visits the download url again. The script used the incorrect image/bmp content type, making the issue manifest with files (1) and (2). It should be noted that the issue was thus far harder to exploit in MyBB and not without social engineering. FluxBB utilized no validation of image files on upload, except a basic file type check. File 3 circumvented that check. SMF (1.1 and 2.0) uses file validation to guard against mime sniffing. However, we found all current versions to be lacking, as they use the getimagesize function to set headers. The files (1) and (2) were able to bypass that defense. Both WBB lite and WBB did not guard sufficiently against file (2) - the obfuscated JS in a valid bitmap - and delivered it with the incorrect header "image/bmp". The software filtered only the presence of "