|
|
composr.png (56,223 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 It... 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. |
- Anonymous
