0011952: Arbitrary inline attachment rendering could lead to cross-domain scripting or other browser attacks - MantisBT - Signup temporarily disabled due to spam

ID	Project	Category	View Status	Date Submitted	Last Update

0011952	mantisbt	security	public	2010-05-23 05:35	2017-03-25 15:29

Reporter	dhx	Assigned To	dhx
Priority	immediate	Severity	block	Reproducibility	always
Status	closed	Resolution	fixed
Product Version	1.2.1
Target Version	1.2.2	Fixed in Version	1.2.2

Summary	0011952: Arbitrary inline attachment rendering could lead to cross-domain scripting or other browser attacks
Description	Kornel Lesinski reported a significant security problem with Mantis' handling of attachments and MIME types. A user could upload a HTML file renamed to .gif and MantisBT would use Fileinfo to calculate the actual MIME type to be text/html. This is a problem because a user could be directed to click on a link purporting to be a .gif attachment when in fact it is a HTML document. Browsers would attempt to render the text/html attachment within the browser instead of treating it as a file download (or even just plaintext). Internet Explorer exaggerates this problem by ignoring the Content-Type header so that it can perform its own analysis of the file type. With the expectation that Fileinfo and any browser MIME detection are inherently insecure and unpredictable, we don't want to allow users to upload random files that could be misinterpreted by MIME detectors for malicious purposes. As we send our own Content-Type headers where appropriate, we can tell Internet Explorer 8+ to stop it's own MIME type sniffing, resulting in a performance boost for IE8+ users.
Tags	No tags attached.

MantisBT: master f017e817 2010-05-23 05:38 dhx Details Diff	Fix 0011952: Arbitrary inline attachment rendering (security issue) Kornel Lesinski reported a significant security problem with Mantis' handling of attachments and MIME types. A user could upload a HTML file renamed to .gif and MantisBT would use Fileinfo to calculate the actual MIME type to be text/html. This is a problem because a user could be directed to click on a link purporting to be a .gif attachment when in fact it is a HTML document. Browsers would attempt to render the text/html attachment within the browser instead of treating it as a file download (or even just plaintext). Internet Explorer exaggerates this problem by ignoring the Content-Type header so that it can perform its own analysis of the file type. With the expectation that Fileinfo and any browser MIME detection are inherently insecure and unpredictable, we don't want to allow users to upload random files that could be misinterpreted by MIME detectors for malicious purposes. As we send our own Content-Type headers where appropriate, we can tell Internet Explorer 8+ to stop it's own MIME type sniffing, resulting in a performance boost for IE8+ users. To solve this problem, a new 'show_inline' parameter has been introduced to file_download.php which serves the purpose of specifying whether the file should be served to the user as an attachment (within the Content-Disposition header) or as an inline file that can be rendered within the browser. This parameter has also been protected using a CSRF token to ensure that cross-domain attacks are not possible whereby a malicious user uploads a HTML document and sends a link to someone else with &show_inline=1 set. This is particularly an issue where an attacker places a MantisBT instance within an invisible iframe such that the HTML attachment is rendered unknown to users (and this HTML attachment could invoke JavaScript to do nasty things within the domain of the MantisBT installation). In summary, MantisBT will treat all attachments as file downloads when it prepares the Content-Disposition header. An exception currently exists for inline image previews where MantisBT will create img src URLs that point to file_download.php with show_inline=1 and a CSRF token parameter provided. The MIME type isn't a significant concern in this case as browsers won't try to render HTML where an image is expected.		Affected Issues 0011952
	mod - core/http_api.php		Diff File
	mod - core/print_api.php		Diff File
	mod - file_download.php		Diff File
	mod - core/file_api.php		Diff File
MantisBT: master-1.2.x 618f45ac 2010-05-23 05:38 dhx Details Diff	Fix 0011952: Arbitrary inline attachment rendering (security issue) Kornel Lesinski reported a significant security problem with Mantis' handling of attachments and MIME types. A user could upload a HTML file renamed to .gif and MantisBT would use Fileinfo to calculate the actual MIME type to be text/html. This is a problem because a user could be directed to click on a link purporting to be a .gif attachment when in fact it is a HTML document. Browsers would attempt to render the text/html attachment within the browser instead of treating it as a file download (or even just plaintext). Internet Explorer exaggerates this problem by ignoring the Content-Type header so that it can perform its own analysis of the file type. With the expectation that Fileinfo and any browser MIME detection are inherently insecure and unpredictable, we don't want to allow users to upload random files that could be misinterpreted by MIME detectors for malicious purposes. As we send our own Content-Type headers where appropriate, we can tell Internet Explorer 8+ to stop it's own MIME type sniffing, resulting in a performance boost for IE8+ users. To solve this problem, a new 'show_inline' parameter has been introduced to file_download.php which serves the purpose of specifying whether the file should be served to the user as an attachment (within the Content-Disposition header) or as an inline file that can be rendered within the browser. This parameter has also been protected using a CSRF token to ensure that cross-domain attacks are not possible whereby a malicious user uploads a HTML document and sends a link to someone else with &show_inline=1 set. This is particularly an issue where an attacker places a MantisBT instance within an invisible iframe such that the HTML attachment is rendered unknown to users (and this HTML attachment could invoke JavaScript to do nasty things within the domain of the MantisBT installation). In summary, MantisBT will treat all attachments as file downloads when it prepares the Content-Disposition header. An exception currently exists for inline image previews where MantisBT will create img src URLs that point to file_download.php with show_inline=1 and a CSRF token parameter provided. The MIME type isn't a significant concern in this case as browsers won't try to render HTML where an image is expected.		Affected Issues 0011952
	mod - file_download.php		Diff File
	mod - core/file_api.php		Diff File
	mod - core/print_api.php		Diff File
	mod - core/http_api.php		Diff File