View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003876||Composr||core||public||2019-09-16 15:16||2019-11-14 21:21|
|Reporter||hexife||Assigned To||Chris Graham|
|Fixed in Version|
|Summary||0003876: XSS vulnerability via mime sniffing on .dat files|
|Description||HTML(XHTML) file can be uploaded in "Home→ Content Management→ Downloads→ Add download" feature.|
(It needs to modify extension to upload-able extension, and edit extension and content-type in the HTTP Request via web debugger (e.g. fiddler, burp). Maybe there is client-side filter in the feature.)
If the file upload is succeed, the path of uploaded file (~.dat) is exposed in its HTTP Response.
(I attached the example image.)
In Apache2 environment (I tested in ubuntu environment) with default setting, when the user access the uploaded file via URL(~.dat file), Web Server couldn't find the content-type of uploaded file and Web server do not set the content-type. It makes the web browsers trying to found file's MIME-Type using their content-sniffing algorithm. If the contents of the file is HTML, Browser determines it as HTML and render it.
|Time estimation (hours)|
composr.png (56,223 bytes)
composr.png (56,223 bytes)
composr_2.png (14,153 bytes)
composr_2.png (14,153 bytes)
Thanks for your report, and posting it as private.
It looks like this is a legitimate bug. I was not aware browsers still did content sniffing.
We'll respond in more detail soon.
Possible fixes to be considered, early stage:
1) Change .dat extension to .bin, which Apache will give an application/octet-stream mime type rather than NO mime type -- add mime handling of .bin handling for IIS via bundled web.config (https://docs.microsoft.com/en-us/iis/configuration/system.webserver/staticcontent/mimemap)
2) Add "X-Content-Type-Options: nosniff" header in bundled .htaccess and web.config
3) Stop using .dat file extension, use original file extension (something to consider in general, but it would require the web server to have mime types set up for every whitelisted file extension - so not plausible to fix this security issue on its own)
4) Make sure direct HTTP access is disabled from any directory with .dat files in
We may do some combination of these things for defense in depth.
This issue is fixed in https://gitlab.com/composr-foundation/composr/commit/8efd2ba863bd8c452039bf4174efbee91dd0ab8b
a) Changes .dat to .bin, which is confirmed to have an application/octet-stream mime type in IIS and Apache. Most browser sniffing won't allow JS to run if an explicit non-JS mime type is being specified, so this alone should fix the issue for any newly uploaded files.
b) Adds "X-Content-Type-Options: nosniff" to the default root .htaccess files and default web.config file. This actually doesn't help to solve the original issue as reported, because (i) Firefox will not consider this header for URLs with no mime type defined [Chromium is okay] (ii) Users would have to manually make the change to the files they have already configured. However, it is good to have this header for possible cases of browsers doing more aggressive mime sniffing.
c) Adds "X-Content-Type-Options: nosniff" and CSP JS-blocking HTTP headers into many directories, basically any that doesn't already completely block web access and doesn't have web pages served from (Composr already sets "X-Content-Type-Options: nosniff" in all its own PHP web requests). This fixes the problems with 'b' because these are not user-edited files, and the CSP will block all JS even if the mime type of old .dat files was sniffed.
d) Generally reviewed all .htaccess files to make sure they are optimal, and added extra testing to ensure consistency here
Direct URL access to uploads/downloads remains, as internally the download system is written under the assumption that every download is associated with a URL. While internally it is passing through dload.php, not every system will necessarily be aware of it.
A second minor vulnerability was found during testing - Composr's internally-generated SVG files for stats graphs had publicly accessible and guessable URLs, leading to leaking of stats data. This has also been fixed, by blocking direct URL access to these files.
Additionally some extra testing is added for v11 to compare Composr-defined mime types against IIS and Apache, to ensure consistency https://gitlab.com/composr-foundation/composr/commit/521d9343d75e2c81acf696e3923527ff75ad711b
This isn't directly related to this vulnerability, but I thought better auditing of our use of mime types will be important.
This issue is not yet public, as work continues on it, and we need to work out exactly how to advise users of the issue. Likely users will be given an option to solve it via a single .htaccess change to add a .dat mime type and add the "X-Content-Type-Options: nosniff" header (which should work for the vast majority of users), rather than applying the full upgrade.
|2019-09-16 15:16||hexife||New Issue|
|2019-09-16 15:16||hexife||Tag Attached: Type: Security|
|2019-09-16 15:16||hexife||File Added: composr.png|
|2019-09-16 15:16||hexife||File Added: composr_2.png|
|2019-09-16 16:59||Chris Graham||Note Added: 0006085|
|2019-09-18 02:13||Chris Graham||Note Added: 0006087|
|2019-09-23 02:06||Chris Graham||Note Added: 0006096|
|2019-09-25 02:01||Chris Graham||Severity||trivial => Security-hole|
|2019-09-25 02:01||Chris Graham||Summary||HTML(XHTML) file could be uploaded in download feature of admin page and rendered under specific server environments. => XSS vulnerability via mime sniffing on .dat files|
|2019-09-25 02:01||Chris Graham||Description Updated||View Revisions|
|2019-09-26 02:31||Chris Graham||Category||downloads => core|
|2019-09-26 02:43||Chris Graham||View Status||private => public|
|2019-11-14 21:21||Chris Graham||Assigned To||=> Chris Graham|
|2019-11-14 21:21||Chris Graham||Status||non-assigned => resolved|
|2019-11-14 21:21||Chris Graham||Resolution||open => fixed|