"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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
> 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?
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.
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.
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.
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.
Does setting pdfjs.enableScripting to false in about:config protect against this? IMO, permitting PDFs to run Javascript violates the Principle of Least Astonishment:
> 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.)
Readit News
https://stackoverflow.com/questions/49299000/what-are-the-se...
"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.
"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.
Deleted Comment
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.
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).
Deleted Comment
> 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.
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.
This too can be harderend against, but it's a significant attack vector in quite a few desktop applications if users don't update.
> 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.
So still no chance in the foreseeable future for this monstrous "paper-based" mockery of docs in a digital age to get phased out?
(Except PDF/A-4, which reintroduces JavaScript for some horrific reason).
Unfortunately, applications that produce broken PDFs are rife, and Postel's law sets the expectation that we should consume garbage and be happy.
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.
- https://www.gnucitizen.org/blog/danger-danger-danger/
- https://blog.jeremiahgrossman.com/2007/01/what-you-need-to-k...
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
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.
> 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.)