4 ms·

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?i

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 https://news.ycombinator.com/item?id=10023517 Let's not give the project a bad name for someone else's bugs.

anon-hn-2 11y ago
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.
fukusa 11y ago
Please have a look at the following comments: https://bugzilla.mozilla.org/show_bug.cgi?id=965003#c5 https://bugzilla.mozilla.org/show_bug.cgi?id=965003#c5 and https://bugzilla.mozilla.org/show_bug.cgi?id=965003#c7 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.
- yAnonymous 11y ago
  Yeah, and that feature was only used in the Firefox deployment of pdf.js. https://github.com/mozilla/pdf.js/commit/4f3f983a214867011dda8c5597a4d3523c5f1423 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.
  - fukusa 11y ago
    That's correct. I don't think we should blame the PDF.js devs either.

anon-hn-2 11y ago

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.

fukusa 11y ago

Please have a look at the following comments: https://bugzilla.mozilla.org/show_bug.cgi?id=965003#c5 https://bugzilla.mozilla.org/show_bug.cgi?id=965003#c5 and https://bugzilla.mozilla.org/show_bug.cgi?id=965003#c7 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.

yAnonymous 11y ago
Yeah, and that feature was only used in the Firefox deployment of pdf.js. https://github.com/mozilla/pdf.js/commit/4f3f983a214867011dda8c5597a4d3523c5f1423 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.
- fukusa 11y ago
  That's correct. I don't think we should blame the PDF.js devs either.