GrapheneOS Organization Explains How Their PDFViewer Is Not Affected By a Vulnerability That Was Discovered In pdf.js

Our PDF Viewer isn’t impacted by issues like this in pdf.js. We use a strict Content Security Policy allowlisting the app’s static CSS and JavaScript without permitting unsafe-eval or unsafe-inline. It’s blocked from using eval or including dynamic JS.

github.com/advisories/GHSA-wgrm-67xf-hhpq

Even if we didn’t set a Content Security Policy, the whole point of the app is that it renders a PDF in a sandboxed WebView instance without network, file or content access. It exposes a fairly small subset of the attack surface exposed by a web browser to any web site you visit.

The only data in the sandboxed WebView instance is the PDF which is written into it by the app without giving it access to the file/content. Even if an attacker somehow got JavaScript code execution despite our strict CSP, they couldn’t do anything beyond attacking the browser.

The reason we use pdf.js is because it’s designed to run efficiently in the browser sandbox. However, unlike opening a website in the browser, we use a restricted environment: no network/file/other access, no dynamic JS or CSS, many features disabled via Permissions Policy, etc.

JavaScript is memory safe but normally has pervasive dynamic code execution via inline JavaScript, dynamically included files and eval. It runs inside a restricted browser sandbox. The browser renderer implementing that sandbox runs inside of the browser’s OS level sandbox.

GrapheneOS uses a hardened WebView provided by Vanadium. On Google certified Android OSes, it’s provided by Chrome. Either way, our approach is far safer than a C++ PDF library in an OS sandbox (isolatedProcess). It provides 2 extra layers of strong security against most attacks.

Exploiting a vulnerability in the PDF library doesn’t really work against our PDF Viewer app since there’s an allowlist for the code. In practice, an attacker would need to exploit Chromium’s rendering indirectly through pdf.js such as targeting browser font/image rendering.

Android uses isolatedProcess for the official PDF rendering library, which lacks our additional layers of protection and is far easier to exploit. Nearly all Android PDF apps bundle their own C or C++ PDF rendering library and don’t bother even using an isolatedProcess sandbox.