Hacker News Reader

Comment by yAnonymous | Hacker News Reader

Apparently the bugs weren't in pdf.js, but in Firefox, and could be exploited through pdf.js and possibly other extensions.

https://news.ycombinator.com/item?id=10023517

Let's not give the project a bad name for someone else's bugs.

View on HN

The original blog post from Mozilla explicitly stated versions of Firefox without pdf.js were unaffected and a Mozilla employee confirmed disabling pdf.js would be enough to protect against the exploit. Mozilla was also extremely cagey about the nature of the exploit, its severity, and who might have been affected by it.

If people were misled into thinking pdf.js was completely to blame, then that's Mozilla's fault.

Please have a look at the following comments: https://bugzilla.mozilla.org/show_bug.cgi?id=965003#c5 and https://bugzilla.mozilla.org/show_bug.cgi?id=965003#c7

As far as I understand PDF.js used the 'PlayPreview' feature (Playpreview is the overlay you get to see to confirm you want to activate a plugin) as a 'hack' to inject PDF.js HTML content (resource://pdf.js/web/viewer.html) into the page because the plugin architecture was not flexible enough. So, even though technically PlayPreview is not part of PDF.js, the combination of PDF.js and PlayPreview specifically made it possible to inject content into PlayPreview and bypass the CSP.

Yeah, and that feature was only used in the Firefox deployment of pdf.js.

https://github.com/mozilla/pdf.js/commit/4f3f983a214867011dd...

Not sure who's to blame, but like he said, there was no vulnerability in the web version.

That's correct. I don't think we should blame the PDF.js devs either.

Reply on news.ycombinator.com