Readit NewsThomasRinsma commented on Show HN: Tetris in a PDF th0mas.nl/downloads/pdftr... · Posted by u/ThomasRinsma
I guess it should read intersection instead of union.
Oops, yeah :)
ThomasRinsma commented on Show HN: Tetris in a PDF th0mas.nl/downloads/pdftr... · Posted by u/ThomasRinsma
"It was a bit tricky to find a union of features that work in both engines [..]"
I am curious what the constraints are to make this work and in which environments it does? Does it work in PDF viewers outside the browser? Is there documentation what is available in which environment? What is enabled by default, can be switched on or off?
I barely looked at Adobe Reader so not sure about that one, it definitely does not work with this PDF though, likely because it's not compliant in several ways. Besides that I wouldn't be surprised if it supports all the required JS APIs and more, just possibly behind some permission prompts.
It might work in Foxit as I believe it supports some scripting. Most of the other native PDF renderers are more static, as far as I know. In either case, I was most interested in the browser-native engines, as I always thought of them as more "static"/limited.
As for documentation on specific features: to be honest, I just looked at the implementations of PDF.js and PDFium. Both only support a subset of the "standard" API, likely for security reasons. But PDF.js for example allows changing a field's background color (colored pixels!), and PDFium allows modifying their position/bounding box (I tried a high res color display by moving a row vertically as if it's a scanline, but things become quite laggy).
ThomasRinsma commented on CVE-2024-4367 – Arbitrary JavaScript execution in PDF.js codeanlabs.com/blog/resea... · Posted by u/todsacerdoti
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 :)
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.
Great work! We had the same idea at the same time, here's my version of PDF Doom:
Source: https://github.com/thomasRinsma/pdfdoom
Playable here: https://th0mas.nl/downloads/doom.pdf
Yours is neater in many ways though!