-
Notifications
You must be signed in to change notification settings - Fork 10.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Eval Function("return this") is not secure #10818
Comments
This is done for performance reasons, and will consequently not be removed; as such this issue is INVALID. However, if you look at the API documentation you'll see that this is already user-configurable when calling Lines 178 to 180 in fef86cc
|
It is happens only in two cases: May be it is happens before you add check isEvalSupported with try catch Could you please help to fine a solution? We can't change the code of lib due to this is a npm module |
What's described in #10818 (comment) sounds like a duplicate of issue #10229 (which wasn't clear from the original comment above). |
Yes, I would agree on the duplicate. |
By default, pdfjs-dist optimizes some path resolution logic by compiling a JavaScript function on the fly. The function is built using string concatenation and no effort is made at sanitizing the parts it is built from. These parts could contain user-input which leads to a code injection vulnerability. This commit disables this default behavior. An alternative is to upgrade pdfjs-dist to v4.2.67 or later. See: - https://bugzilla.mozilla.org/show_bug.cgi?id=1893645 - https://www.cve.org/CVERecord?id=CVE-2024-4367 - https://security.snyk.io/vuln/SNYK-JS-PDFJSDIST-6810403 - GHSA-wgrm-67xf-hhpq. - mozilla/pdf.js#18015 - wojtekmaj/react-pdf#1786 - https://security.stackexchange.com/questions/248462/is-firefoxs-new-javascript-support-within-pdf-files-a-security-concern/248985#248985 - https://stackoverflow.com/questions/49299000/what-are-the-security-implications-of-the-isevalsupported-option-in-pdf-js - mozilla/pdf.js#10818
By default, pdfjs-dist optimizes some path resolution logic by compiling a JavaScript function on the fly. The function is built using string concatenation and no effort is made at sanitizing the parts it is built from. These parts could contain user-input which leads to a code injection vulnerability. This commit disables this default behavior. An alternative is to upgrade pdfjs-dist to v4.2.67 or later. For reference, see: - https://bugzilla.mozilla.org/show_bug.cgi?id=1893645 - https://www.cve.org/CVERecord?id=CVE-2024-4367 - https://security.snyk.io/vuln/SNYK-JS-PDFJSDIST-6810403 - GHSA-wgrm-67xf-hhpq - mozilla/pdf.js#18015 - wojtekmaj/react-pdf#1786 - https://security.stackexchange.com/questions/248462/\ is-firefoxs-new-javascript-support-within-pdf-files-a-security-concern/\ 248985 - https://stackoverflow.com/questions/49299000/\ what-are-the-security-implications-of-the-isevalsupported-option-in-pdf-js - mozilla/pdf.js#10818 Not sure if this will break anything and/or will make certain things slower.
By default, pdfjs-dist optimizes some path resolution logic by compiling a JavaScript function on the fly. The function is built using string concatenation and no effort is made at sanitizing the parts it is built from. These parts could contain user-input which leads to a code injection vulnerability. This commit disables this default behavior. An alternative is to upgrade pdfjs-dist to v4.2.67 or later. See: - https://bugzilla.mozilla.org/show_bug.cgi?id=1893645 - https://www.cve.org/CVERecord?id=CVE-2024-4367 - https://security.snyk.io/vuln/SNYK-JS-PDFJSDIST-6810403 - GHSA-wgrm-67xf-hhpq. - mozilla/pdf.js#18015 - wojtekmaj/react-pdf#1786 - https://security.stackexchange.com/questions/248462/is-firefoxs-new-javascript-support-within-pdf-files-a-security-concern/248985#248985 - https://stackoverflow.com/questions/49299000/what-are-the-security-implications-of-the-isevalsupported-option-in-pdf-js - mozilla/pdf.js#10818
By default, pdfjs-dist optimizes some path resolution logic by compiling a JavaScript function on the fly. The function is built using string concatenation and no effort is made at sanitizing the parts it is built from. These parts could contain user-input which leads to a code injection vulnerability. This commit disables this default behavior. An alternative is to upgrade pdfjs-dist to v4.2.67 or later. For reference, see: - https://bugzilla.mozilla.org/show_bug.cgi?id=1893645 - https://www.cve.org/CVERecord?id=CVE-2024-4367 - https://security.snyk.io/vuln/SNYK-JS-PDFJSDIST-6810403 - GHSA-wgrm-67xf-hhpq - mozilla/pdf.js#18015 - wojtekmaj/react-pdf#1786 - https://security.stackexchange.com/questions/248462/\ is-firefoxs-new-javascript-support-within-pdf-files-a-security-concern/\ 248985 - https://stackoverflow.com/questions/49299000/\ what-are-the-security-implications-of-the-isevalsupported-option-in-pdf-js - mozilla/pdf.js#10818 Not sure if this will break anything and/or will make certain things slower.
Attach (recommended) or Link to PDF file here:
Configuration:
Steps to reproduce the problem:
What is the expected behavior? (add screenshot)
Please replace Function("return this") with not eval approach. Thanks a lot!
What went wrong? (add screenshot)
Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):
The text was updated successfully, but these errors were encountered: