Headline
CVE-2022-1091: Better checking of the file type when determining which files are SVGs by dkotter · Pull Request #28 · 10up/safe-svg
The sanitisation step of the Safe SVG WordPress plugin before 1.9.10 can be bypassed by spoofing the content-type in the POST request to upload a file. Exploiting this vulnerability, an attacker will be able to perform the kinds of attacks that this plugin should prevent (mainly XSS, but depending on further use of uploaded SVG files potentially other XML attacks).
Description of the Change
We currently have a function that is hooked into the wp_handle_upload_prefilter filter. In there we check if the file type is image/svg+xml and if so, we sanitize the file. If that sanitization process fails, we don’t allow the file to be uploaded to WordPress.
There’s a potential issue here though because the file type we rely on comes from the Content-Type of the original form-data request. Typically this will be automatically set to whatever the real file type is but in theory, someone could spoof this request and set Content-Type to be anything, like image/png. In this case, they could send an actual SVG in the form-data but set the Content-Type to be image/png, which would then bypass our sanitization process (but would still be uploaded to WordPress).
This PR fixes this by utilizing the core WordPress function wp_check_filetype_and_ext to get the file type, instead of relying on the value that comes from the request. This should still work in all legitimate cases and if someone were to try sending a proper SVG but they change the Content-Type in the request, it will also catch that.
I tested the following scenarios:
- Valid SVG uploaded without a custom
Content-Typeset. Our sanitization kicks in ✅ - Valid SVG uploaded with a custom
Content-Typeset (set toimage/png). Our sanitization kicks in ✅ - Valid PNG uploaded without a custom
Content-Typeset. No sanitization needed from us ✅ - SVG file with a .png extension uploaded without a custom
Content-Typeset. File rejected ✅ - SVG file with a .png extension uploaded with a custom
Content-Typeset. File rejected ✅ - SVG file with no extension uploaded without a custom
Content-Typeset. File rejected ✅ - SVG file with no extension uploaded with a custom
Content-Typeset. File rejected ✅
Alternate Designs
None
Possible Drawbacks
Slight impact on performance but should be minimal
Verification Process
Ensure that you can still properly upload SVGs in WordPress.
If desired, can also manually make a curl request to send an SVG with a manipulated Content-Type field, to verify that captures things correctly. I can provide an example curl command if needed.
Checklist:
- I have read the CONTRIBUTING document.
- My code follows the code style of this project.
- My change requires a change to the documentation.
- I have updated the documentation accordingly.
- I have added tests to cover my change.
- All new and existing tests passed.
Changelog Entry
Fixed - add better file type checking when looking for SVG files
Related news
fleetdm/fleet is an open source device management, built on osquery. All versions of fleet making use of the teams feature are affected by this authorization bypass issue. Fleet instances without teams, or with teams but without restricted team accounts are not affected. In affected versions a team admin can erroneously add themselves as admin, maintainer or observer on other teams. Users are advised to upgrade to version 4.13. There are no known workarounds for this issue.
PyPDF2 is an open source python PDF library capable of splitting, merging, cropping, and transforming the pages of PDF files. In versions prior to 1.27.5 an attacker who uses this vulnerability can craft a PDF which leads to an infinite loop if the PyPDF2 if the code attempts to get the content stream. The reason is that the last while-loop in `ContentStream._readInlineImage` only terminates when it finds the `EI` token, but never actually checks if the stream has already ended. This issue has been resolved in version `1.27.5`. Users unable to upgrade should validate and PDFs prior to iterating over their content stream.
A flaw was found in cri-o, where containers were incorrectly started with non-empty default permissions. A vulnerability was found in Moby (Docker Engine) where containers started incorrectly with non-empty inheritable Linux process capabilities. This flaw allows an attacker with access to programs with inheritable file capabilities to elevate those capabilities to the permitted set when execve(2) runs.