Full Report
DomPDF is an HTML to PDF converter for PHP. In the past, a vulnerability was found that allowed for code execution in PHP. CSS font can be remotely loaded with any extension, leading to code execution if a user can access that specific file. From the previous research, the author noted that the fix was to force font extensions to have .ttf. Additionally, it doesn't address the fact that arbitrary contents can be present in a font file or the arbitrary file upload issue. The author decided to look for a work around for the original patch. In another previous vulnerability (CVE-2021-3838), the author noted that the phar:// URI could be put into any HTML elements. To fix this vulnerability, an allowlist of URIs was put into DomPDF. Reviewing previous vulnerabilities in applications can be extremely beneficial. First, vulnerabilities tend to come in pairs. Second, only 75% of patches are sufficient, according to Natalie from Project Zero. This can be free vulnerabilities and help teach people where to look. The code from the phar deserailization vulnerability was not sufficient. Even when the protocol is not in the allowlist, the code flow does NOT return. This means that the file content will still be gathered. In the actual code for getting the file (getFileContent) still parses phar:// and file:// URIs. Because of the issue mentioned above, we can use the phar:// URI to trigger a deserialization vulnerability for code execution. In the previous exploit, the isRemoteEnabled option has to be enabled in order to trigger the vulnerability. However, by caching the data:// URI in the CSS file, we can store this as a file. Then, in a second request, we can request the data file path as a phar file. This removes the need for the special flag to be enabled. A polyglot tiff and phar (serialized PHP) had to be created for this. Lucky for us, PHP is really lenient with parsing. Since we can execute arbitrary PHP code, we now have remote code execution! Overall, great blog post on real world vulnerability hunting. It was cool to see the improvement on previous exploits on DomPDF as well.
Analysis Summary
# Vulnerability: RCE via Phar Deserialisation in Dompdf due to Insufficient URI Validation
## CVE Details
- CVE ID: CVE-2022-41343
- CVSS Score: Not explicitly provided in the text. (Inferred Severity: High due to RCE)
- CWE: CWE-502 (Deserialization of Untrusted Data) in context of URI handling.
## Affected Systems
- Products: DomPDF (PHP HTML to PDF converter)
- Versions: 2.0.0 and below (Prior to v2.0.1)
- Configurations: Exploitation success is noted to bypass previous checks (like `isRemoteEnabled`) by chaining vulnerabilities.
## Vulnerability Description
This vulnerability exploits insufficient validation of URI protocols during file content retrieval, specifically in how Dompdf handles file reading, which includes functionality like `getFileContent`.
The fix for a previous vulnerability (CVE-2021-3838), which restricted protocols in the `$allowedProtocols` list (to `file://`, `http://`, `https://`), was incomplete. The underlying code flow in `getFileContent` still parses protocols like `phar://` even if they are not in the allowlist, meaning file content is still gathered.
By coupling this with the remaining flaw identified from a prior font-caching vulnerability (where arbitrary files could be written to a cache directory, potentially as a polyglot TIFF/PHAR file), an attacker can construct a malicious payload. The attack involves:
1. Caching a `data://` URI containing a polyglot TIFF/PHAR file (containing serialized PHP data) as what appears to be a font file in the cache.
2. Making a second request that requests the path to this cached file using the `phar://` wrapper.
3. This triggers PHP's deserialization mechanism, leading to Remote Code Execution (RCE).
This method bypasses the need for the `isRemoteEnabled` option to be true, which was a requirement for the original `phar://` deserialization exploit.
## Exploitation
- Status: PoC available (Based on the detailed description of the exploit chain, including the creation of a polyglot file).
- Complexity: Medium (Requires chaining two distinct vulnerabilities/flaws, including creating a specialized polyglot file).
- Attack Vector: Network (Requires an attacker to initiate the process that causes Dompdf to render content, likely via HTML input containing CSS).
## Impact
- Confidentiality: High (RCE allows access to server data and credentials).
- Integrity: High (RCE allows manipulation or destruction of data/system integrity).
- Availability: High (RCE allows for system shutdown or denial of service).
## Remediation
### Patches
- Update Dompdf to **v2.0.1** or later.
### Workarounds
- No explicit, direct workarounds are provided for CVE-2022-41343 specifically, other than performing the upgrade. Prior advice related to the font caching vulnerability (preventing arbitrary file uploads/ensuring font extensions are strictly `.ttf`) is now insufficient or has been superseded by the need to patch the URI parsing flaw.
## Detection
- **Indicators of Compromise (IoCs):** Look for file access attempts against the Dompdf cache directories utilizing the `phar://` protocol wrapper on file paths that appear to correspond to cached documents or fonts.
- **Detection Methods and Tools:** Application Security Testing (AST) tools or source code review should flag non-allowed protocol usage in file reading functions (e.g., `getFileContent`) if they do not explicitly check and filter against hazardous streams like `phar://`.
## References
- Vendor Advisory (Implied by v2.0.1 release): Dompdf GitHub release history or announcements.
- Relevant Links:
- Previous vulnerability discussed: CVE-2021-3838
- Related Blog Post: hXXps://positive.security/blog/dompdf-rce
- Patch Diff Link (Related to previous vulnerability fix): hXXps://github.com/dompdf/dompdf/pull/2808/files/00b2b360ace768d58430f1cc5a20cb43d58bbc1a#diff-a0473fa74c65efedd487f657d52cb196245a84d2b13e622818dd0d7283da6d38