There is a vulnerability in Composr's storage of uploads as .dat files on servers. A hacker could plant code with JavaScript, then trick an administrator to running it on their machine.

This is a low-to-medium risk vulnerability. With planning, creativity, and coordination, this could result in a hacker attaining various malicious outcomes. JavaScript code does not have access to files on a user's own computer, but it can be used to automate privileged web page actions on the website it is running on.

Affects

All Composr (and ocPortal) versions are affected.
Apache servers are affected, but IIS servers are usually not.

Available resolutions

Upgrade Composr

Version 10.0.29 has been released and fixes the security hole.

Workaround

Apache users may simply add the following code to their main .htaccess file:

This requires the Apache mod_headers module being enabled, which probably is.

IIS users may upload the latest web.config from 10.0.29, which includes the equivalent code. However, IIS users are only affected if their server has been specially configured to serve .dat files or to serve all file types (IIS won't by default serve unknown file extensions).

Checking for exploit attempts

.dat files containing HTML can be located on Linux with this command:

Technical explanation

The web is designed around the idea of URLs (usually attached to files, but not necessarily) having mime-types. The mime-type determines how a web browser will treat the URL.
For example, an HTML document would typically have a text/html mime-type.
Web servers will automatically assign mime-types to served files based on file extensions.

Composr will use .dat files for files that should have no mime-type, such as download or attachment files held on disk that are not designed to be accessed directly. Web servers provide no mime-type for .dat files, by default.

This should theoretically be secure. However, in practice web browsers may implement mime-type "sniffing", where URLs with no mime-type are assigned a mime-type based on the probed content of the files.
Some browsers may even implement sniffing where they will change what they consider an incorrectly declared mime-type based on the same kind of probing.

How the fix works

This has been fixed on multiple levels, as the defense-in-depth strategy we aim to deploy.

1. Version 10.0.29 changes .dat to .bin for new uploads. Apache and IIS both define .bin with an application/octet-stream (which basically means a generic downloadable file). Most browsers will therefore no longer do mime-sniffing.
2. Version 10.0.29 enables the X-Content-Type-Options="nosniff" header across all Composr files, so that browsers that do more aggressive mime-sniffing, won't. This also is confirmed to stop Chromium-based browsers from doing any mime-sniffing, even for .dat files (not Firefox though).
3. Version 10.0.29 disables JavaScript execution using CSP (Content Security Policy) in many directories where it is not needed, including any directories where .dat files have been placed. This means that even if mime-sniffing happens and a file is executed as HTML, no JavaScript code can run in that file.

The posted workaround is a little different. It actually adds a web server mime-type for .dat files so they behave like .bin files, while also enabling the X-Content-Type-Options="nosniff" header. It is a robust fix for users who do not want to upgrade.

Lessons learned

The developers were not aware that the described standards-incompliant mime-sniffing still existed outside very old versions of Internet Explorer, and were not aware it would happen on URLs with no mime-type.
Now that we are aware, we have triple-fixed the issue as described above.

Credit

This issue was privately reported to us on the 16th September, and we are always appreciative of people who report vulnerabilities to us in responsible ways, as has happened here. Responsible security researchers help keep Composr secure.

Credit: Taekjin Lee, Seongil Wi, Suyoung Lee, Sooel Son from WSP Lab, KAIST.