arbitrary code execution in PDF.js.
a malicious PDF can execute arbitrary JS as soon as it's opened in Firefox.
https://codeanlabs.com/blog/research/cve-2024-4367-arbitrary-js-execution-in-pdf-js/
how do you fuck up so bad as to allow arbitrary code execution? what was the justification for using eval() for glyph rendering
2024 may not be the year of Linux on the desktop, but it sure is the year of XSS via malicious glyphs on a PDF
right, so the justification for using eval() was doing some kind of JIT on the glyph commands. and the code that generated the compiled JS did some very poor validation of the parsed JS objects it used.
I'm going to put
// eslint-disable-next-line no-new-func
high up on the shelf until y'all learn how to use it
it is a bit outrageous honestly. all this effort on the JS runner to make sure PDF.js is safe, and then someone just... pastes an arbitrary string into a JS function that is going to be eval'ed 
and this bug has been present since PDF.js was released in 2014
except for a 1-year period because someone made a typo that disabled the bug.
security is a joke.
so, to be crystal clear: those of you who use Firefox could've had arbitrary JS executed for the last decade, with a very reliable and VERY easy to exploit bug.
now my question is, what could an attacker have done with it? what are the permissions in which the Firefox PDF viewer's JS is executed?
@mildsunrise doesn't that just make a malicious pdf as insecure as a malicious website (which can already execute arbitrary js)
@noiob but I haven't really looked so I could be wrong, maybe they apply special restrictions on the file: origin (or a CSP)
or on the other hand, maybe they give the code special permissions since it is part of the browser's core
@ugackMiner @noiob thanks, that's a relief
@mildsunrise @noiob my interpretation of the docs is that JS from file origin can't read arbitrary other files in a modern browser today. However, it's implementation defined so 🤷♂️
https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#file_origins
How universally true that is, and when it became the expectation, I don't know.
@noiob the PDF viewer (for a downloaded file) isn't executed in the context of a website, since it is a file:// URL. logic tells me it should be able to access arbitrary files in your computer and maybe also requests to a (possibly malicious, exfiltration target) server