PDF Viewer will convert PostScript calculator functions to JavaScript. While the PostScript code itself is being validated thoroughly, for the Domain and Range parameters in the PDF file the code will only verify that these are arrays (see https://dxr.mozilla.org/mozilla-central/rev/2f5ffe4fa2153a798ed8b310a597ea92abd1b868/browser/extensions/pdfjs/content/build/pdf.worker.js#20413). PostScriptCompiler will then insert the array entries into the generated JavaScript code verbatim assuming that these are numbers (as they should be per spec), a malicious PDF file can use strings to inject JavaScript code this way. Steps to reproduce: 1. Press Ctrl+Shift+J to open Browser Console. 2. Switch back to the browser and open the attached PDF file. 3. Check the Browser Console. In Firefox 59.0.2 and 61.0a1 (2018-04-06) nightly the following message shows up in Browser Console: "Hello, this is code running in resource://pdf.js/build/pdf.worker.js." You can look at the text of the PDF file to see that the code being executed here is console.log("Hello, this is code running in " + location.href). I did not implement additional exploit steps but code running in the worker can jump over to the viewer itself. For that it would send a malicious glyph to the viewer, you can see under https://dxr.mozilla.org/mozilla-central/rev/2f5ffe4fa2153a798ed8b310a597ea92abd1b868/browser/extensions/pdfjs/content/build/pdf.js#6354 that glyph data is being used to produce JavaScript code without further validation - this code assumes that validation happens in the worker. Once in the viewer, the code could trigger the ChromeActions API available to the viewer (see https://dxr.mozilla.org/mozilla-central/rev/2f5ffe4fa2153a798ed8b310a597ea92abd1b868/browser/extensions/pdfjs/content/PdfStreamConverter.jsm#191) and read/write preferences in the pdfjs.* namespace for example. Also, it could add iframe tags pointing to other PDF files (e.g. from intranet domains). Since PDF Viewer would load into these domains as well, it could access their contents (same-origin) and steal PDF data.
Bug 1452075 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
PDF Viewer will convert PostScript calculator functions to JavaScript. While the PostScript code itself is being validated thoroughly, for the Domain and Range parameters in the PDF file the code will only verify that these are arrays (see https://hg.mozilla.org/mozilla-central/file/2f5ffe4fa2153a798ed8b310a597ea92abd1b868/browser/extensions/pdfjs/content/build/pdf.worker.js#l20413). PostScriptCompiler will then insert the array entries into the generated JavaScript code verbatim assuming that these are numbers (as they should be per spec), a malicious PDF file can use strings to inject JavaScript code this way. Steps to reproduce: 1. Press Ctrl+Shift+J to open Browser Console. 2. Switch back to the browser and open the attached PDF file. 3. Check the Browser Console. In Firefox 59.0.2 and 61.0a1 (2018-04-06) nightly the following message shows up in Browser Console: "Hello, this is code running in resource://pdf.js/build/pdf.worker.js." You can look at the text of the PDF file to see that the code being executed here is console.log("Hello, this is code running in " + location.href). I did not implement additional exploit steps but code running in the worker can jump over to the viewer itself. For that it would send a malicious glyph to the viewer, you can see under https://hg.mozilla.org/mozilla-central/file/2f5ffe4fa2153a798ed8b310a597ea92abd1b868/browser/extensions/pdfjs/content/build/pdf.js#l6354 that glyph data is being used to produce JavaScript code without further validation - this code assumes that validation happens in the worker. Once in the viewer, the code could trigger the ChromeActions API available to the viewer (see https://hg.mozilla.org/mozilla-central/file/2f5ffe4fa2153a798ed8b310a597ea92abd1b868/browser/extensions/pdfjs/content/PdfStreamConverter.jsm#l191) and read/write preferences in the pdfjs.* namespace for example. Also, it could add iframe tags pointing to other PDF files (e.g. from intranet domains). Since PDF Viewer would load into these domains as well, it could access their contents (same-origin) and steal PDF data.