CVE-2024-4367 – Arbitrary JavaScript execution in PDF.js

https://codeanlabs.com/blog/research/cve-2024-4367-arbitrary-js-execution-in-pdf-js/

by todsacerdoti • 2 years ago

207 102 2 years ago

kyrra• 2 years ago

The impact here is XSS or possible RCE for electron.

In applications that embed PDF.js, the impact is potentially even worse. If no mitigations are in place (see below), this essentially gives an attacker an XSS primitive on the domain which includes the PDF viewer. Depending on the application this can lead to data leaks, malicious actions being performed in the name of a victim, or even a full account take-over. On Electron apps that do not properly sandbox JavaScript code, this vulnerability even leads to native code execution (!). We found this to be the case for at least one popular Electron app.

plingbang• 2 years ago

I remember MS Teams opening various files within itself instead of launching an appropriate program. I wonder what they're using for rendering PDFs.

gostsamo• 2 years ago

At least edge uses a module from word as far as I know and I'd expect the same for teams. They likely are not affected.

Gare• 2 years ago

That's why I use MS Teams (on desktop) via browser only. Keeps it nicely sandboxed.

mattsan• 2 years ago

Haven't tested but I'm almost certain the Electron app they're talking about is VS Code. Wouldn't make sense for a code editor to sandbox extensions

notnullorvoid2• 2 years ago

I don't believe they are talking about a VS Code extension embedding PDF.js but rather an Electron app that has PDF.js embedded by default. My guess is Slack.

jgtrosh• 2 years ago

This affects all Firefox users (<126)

I suppose/hope this is version number and not a dig at the market share

yyhhsj0521• 2 years ago

126 was released just on 2024-5-14. So the majority of FF users especially those who get FF from a more stable package manager repo.

azeemba2• 2 years ago

The poster was joking that it looks like there are less than 126 Firefox users

gpm2• 2 years ago

I'd guess reasonably confidently that the majority of firefox users, are on window or mac, got firefox from the web, have auto updates enabled, and are already on 126 (they've had a week to update at this point).

With the exception of LTS releases, if you haven't got firefox 126 yet because you're on a "stable" package manager, I'd encourage you to promptly download firefox from mozilla.org (which will come with auto-updates) and uninstall your package managers insecure version. Given the state of the web and software security web browsers aren't something you should be delaying updating by a week.

philsnow• 2 years ago

Given the abundance of desktop electron apps, it seems maybe irresponsible to publish this blog post (with an advertisement for Codean in the middle (which itself was at least tastefully done)) only 6 days after the fix was released and the CVE was published.

Yes, a fix landed in Firefox, but the vuln is in pdf.js, and now I’m giving the ol side-eye to the four or five electron apps I have running.

TacticalCoder• 2 years ago

https://security-tracker.debian.org/tracker/CVE-2024-4367

It's already fixed in Debian stable (firefox-esr version 115).

It's fixed by default in FF 126+. But, as I understand it, older versions like the one in Debian stable, can be (and are already) patched.

ttrrooppeerr• 2 years ago

Having 2007 flashback to the UXSS in Adobe Acrobat Reader Plugin:

- https://www.gnucitizen.org/blog/danger-danger-danger/

- https://blog.jeremiahgrossman.com/2007/01/what-you-need-to-k...

eviks6• 2 years ago

The PDF format is famously complex. With support for various media types, complicated font rendering and even rudimentary scripting, PDF readers are a common target for vulnerability researchers.

So still no chance in the foreseeable future for this monstrous "paper-based" mockery of docs in a digital age to get phased out?

rrr_oh_man• 2 years ago

What's the alternative?

jandrese• 2 years ago

Eps, but it is not much better.

jl67• 2 years ago

PDF/A. All the good bits of PDF (compatibility, standardization, encapsulation), without the worst bits (media extensions, JavaScript).

(Except PDF/A-4, which reintroduces JavaScript for some horrific reason).

niutech2• 2 years ago

OpenXPS (https://en.wikipedia.org/wiki/Open_XML_Paper_Specification), DjVu (https://en.wikipedia.org/wiki/DjVu).

pjmlp• 2 years ago

Sure, if you come up with something that covers all PS and PDF use cases.

niutech2• 2 years ago

What about OpenXPS (ECMA-388)?

sneed_chucker• 2 years ago

https://xkcd.com/927/

Dalewyn• 2 years ago

Paper is still very much a thing in business and office work. PDFs allowing a near perfect translation between computer monitor and paper is an absolutely critical piece of technological infrastructure.

rough-sea• 2 years ago

use deno!

https://docs.deno.com/runtime/manual/basics/permissions

kevinyew• 2 years ago

This doesn't make any sense, this vulnerability is in the context of browsers, not server side runtimes.

jerrygenser• 2 years ago

Found this fun stack overflow post:

https://stackoverflow.com/questions/49299000/what-are-the-se...

pixl97• 2 years ago

That poor incorrect post in that thread from 2018.

naberhausj2• 2 years ago

Like I asked the other person in this thread, what's wrong with that answer?

Not only does it correctly identify the attack vector of this CVE, but I think his advice on how to mitigate it is sound. Is there something I'm missing? The only flaw I see is that it doesn't consider the implications of using PDF.js in Electron.

tgsovlerkhgsel4• 2 years ago

It's not even incorrect.

The option isn't supposed to allow XSS-by-design (which the original requester was worried about), the possibility of a vulnerability is mentioned, the impact of a vulnerability is correctly described (XSS not RCE or similar), and mitigations that would effectively limit the impact of such a vulnerability are presented (separate origin).

daghamm2• 2 years ago

Accepted answer:

"Potentially, there is a tiny possibility... Keep in mind, it's a web application, and worse it can do is XSS attack"

One sad thing about security is that everyone and their uncle is a security expert.

baobabKoodaa2• 2 years ago

What is wrong with that accepted answer?

naberhausj2• 2 years ago

That answer goes on to say,

"If you serve untrusted PDFs in a PDF viewer and you are hosting at your location, it is better be located at different origin than your main app, www.example.org vs pdfviewer.example.org."

My understanding is that this CVE is an XSS attack, so isn't this advice sound? The RCE portion of this CVE is for Election, where every XSS attack is twice as fun.

Is there something about his answer that is wrong that I don't see? I hardly think we can fault someone simply for having faith in the integrity of software that everyone else trusted until now.

Art9681• 2 years ago

Another sad thing is that no matter the accolades of the "security expert", the truth is that they havent been "hacked" because they or their business has nothing of value to those skilled enough to take it. "I can" doesn't mean "I want to", or "it's worth our time". Which is to say, everyone is an expert, until they are not.

hulitu2• 2 years ago

JavaScript-based PDF viewer maintained by Mozilla. This bug allows an attacker to execute arbitrary JavaScript code as soon as a malicious PDF file is opened. This affects all Firefox users (<126) because PDF.js is used by Firefox to show PDF files, but also seriously impacts many web- and Electron-based applications that (indirectly) use PDF.js for preview functionality.

I don't use Firefox to view PDFs. But it seems that the new MS Windows echosystem might be affected.

djtango2• 2 years ago

Is Android Chrome the same Chromium engine as desktop? I don't know much about the mobile browser internals.

gruez7• 2 years ago

But it seems that the new MS Windows echosystem might be affected.

Why? Does the microsoft pdf viewer use pdf.js internally? Edge at least is based on chromium, and chromium AFAIK uses pdfium rather than pdf.js.

hulitu2• 2 years ago

but also seriously impacts many web- and Electron-based applications that (indirectly) use PDF.js for preview functionality.

perlgeek• 2 years ago

    $  sudo snap refresh firefox 
    firefox 126.0-2 from Mozilla refreshed

I'm not always happy about the snap mechanism, but this time I'm glad about a quick release/packaging channel. Kudos to the firefox snap maintainers!

cwillu2• 2 years ago

How is that any different from any other package manager? The sandboxing features of snaps have no major role in how easy it is for a publisher to update a package in one of their repositories.

planede• 2 years ago

Right. But you also get a recent one if you just use the Mozilla PPA, without snap. Debian sid also ships 126, and I assume the fix should be backported to Firefox LTS, which is used by stable.

I don't see the relevance of snap here.

tgsovlerkhgsel4• 2 years ago

If you had to manually refresh it and were on a vulnerable version until now, snap failed to get you into a secure state for about a week after the release of the fixed version.

superkuh• 2 years ago

"Web browser executes javascript" is not exactly shocking. Every single browser in it's default configuration does before the proper NoScript (or NoScript-alike) is added. This doesn't seem like a significant vulnerability since it is the default mode of operation of modern web browsers. Use a pdf reader if you want something moderately more secure.

cwillu2• 2 years ago

The problem is embedding a browser into an app that may not maintain the same security boundaries as a “proper” web browser.

djtango2• 2 years ago

I recently got a couple of dodgy emails with an invoice.pdf or equivalent. Never seen that type of email before, I thought it prudent not to open the PDF

Wonder if it was related...

gruez7• 2 years ago

While pdf 0days do exist, they're patched fairly quickly once known and therefore attackers are likely not going to waste them on non-targeted attacks. Assuming you keep your software up to date and aren't a high value target, you probably don't have to worry about pdf 0days. The spam you're getting with pdfs are likely using pdfs because it's easier to evade spam filters, not because there's a pdf 0day embedded inside.

kibwen2• 2 years ago

Arbitrary code execution, though only of Javascript, so (as far as the browser use case is concerned) the risk compared to visiting any website (other than the potential for XSS) is that the context that it's running in is slightly elevated (though still much less than having full control of your machine):

PDF.js runs under the origin resource://pdf.js. This prevents access to local files, but it is slightly more privileged in other aspects. For example, it is possible to invoke a file download (through a dialog), even to “download” arbitrary file:// URLs. Additionally, the real path of the opened PDF file is stored in window.PDFViewerApplication.url, allowing an attacker to spy on people opening a PDF file, learning not just when they open the file and what they’re doing with it, but also where the file is located on their machine.

toxik2• 2 years ago

If you can upload a PDF and have it served on the root domain, eg, gmail.com, then you can do session hijacking and other XSS. It’s actually pretty bad. XSS used to be thought of as “not that bad”, but today it is considered pretty bad.

kibwen2• 2 years ago

Yes, I'm not here to downplay the severity of XSS. Rather, I'm trying to be specific about the potential attack vector here.

If you're just viewing a PDF using the built-in pdf.js in Firefox, then (AFAIK) it doesn't matter what site you downloaded it from, because pdf.js isn't running in the context of the website, so it doesn't have access to that site's locally-stored data (including cookies). Instead it's running in the origin mentioned above, with the accompanying concerns.

So the XSS (again, as far as a web browser is concerned) would be if the site itself is shipping pdf.js for viewing PDFs inside the webpage itself. As you suggest, Gmail lets you preview PDFs, so XSS would be a concern there, but only if Gmail is using pdf.js.

tgsovlerkhgsel4• 2 years ago

How would serving the PDF on a sensitive origin help the attacker? Wouldn't they need to serve the vulnerable PDF viewer on a sensitive origin?

iudqnolq• 2 years ago

Wouldn't that take a separate vulnerability? This is why Google serves attachments off something like googleusercontent.com.

jeroenhd• 2 years ago

The risk is higher in Electron/Tauri applications, which often expose native code paths to the application Javascript, as the script executed is supposed to come exclusively from the application developers.

This too can be harderend against, but it's a significant attack vector in quite a few desktop applications if users don't update.

jl67• 2 years ago

Strict validation could theoretically have helped here, as /FontMatrix is required by the PDF spec to be an array of six numbers. The exploit string was syntactically valid but semantically invalid.

Unfortunately, applications that produce broken PDFs are rife, and Postel's law sets the expectation that we should consume garbage and be happy.

notnullorvoid2• 2 years ago

Postel's law should not be applied so broadly, and certainly shouldn't be used as an argument against further validation of inputs.

Garbage inputs are the responsibility of the sender, not the receiver. You can and should accept a small margin of error in inputs where errors may logically appear, but if the receiver accepts too much error then it becomes responsible by creating a complicit norm. If the responsibility of error remains on the sender then introducing further validation is less likely to cause breakage in communication.

tmsbrg2• 2 years ago

I guessed this is a type of XSS but it seems not. The TL;DR is a bit vague on the impact. It says "This bug allows an attacker to execute arbitrary JavaScript code as soon as a malicious PDF file is opened" but PDFs can already execute arbitrary JavaScript as a feature (as noted in the article).

Hidden in some paragraph it does say

Instead, PDF.js runs under the origin resource://pdf.js. This prevents access to local files, but it is slightly more privileged in other aspects.

Seems like it's not an XSS letting you take over the website origin, but it lets you run JS under this resource://pdf.js origin. Could be an interesting vector when combined with other weaknesses, but not an instant knock out as I expected when I read the title and saw the points :)

ThomasRinsma• 2 years ago

Original author here. This is indeed a bit confusing.

You are right for the case where Firefox's PDF.js is used (local or remote file in a tab or iframe). The XSS problem however is with web-applications that themselves use PDF.js. In that case, it does not run in a separate or special origin; that is a Firefox thing.

You are also right that the PDF format supports JavaScript, but that is something unrelated to this, and indeed highly sandboxed in all cases.

tmsbrg2• 2 years ago

Thanks for the explanation! That makes it more clear. Nice research and thanks for the reply.

MartijnHols• 2 years ago

A good Content Security Policy [1] could prevent this as well as nullify the impact. If you're embedding a PDF in your app, you really should have one set up.

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

mrob• 2 years ago

Does setting pdfjs.enableScripting to false in about:config protect against this? IMO, permitting PDFs to run Javascript violates the Principle of Least Astonishment:

https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

Common sense suggests PDFs are the digital equivalent of paper documents. Paper documents can't run Javascript, so PDFs shouldn't either.

jmull• 2 years ago

No. From the article:

You might be surprised to hear that this bug is not related to the PDF format’s (JavaScript!) scripting functionality. Instead, it is an oversight in a specific part of the font rendering code.

It goes on to explain that pdfjs dynamically constructs and executes javascript functions as an optimization for rendering older fonts. Certain arguments pulled from the PDF were not escaped, validated, or delimited (the values were expected to be numbers), so you could inject arbitrary JS. (At least that's how I read it.)

issafram• 2 years ago

This affects all Firefox users (<126)

This made me chuckle

CVE-2024-4367 – Arbitrary JavaScript execution in PDF.js

Related Stories