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.
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.
Likewise, an update for the PDF viewer had been pushed as soon as the new version was released to have the patched pdf.js version.
Information about the vulnerability: https://github.com/advisories/GHSA-wgrm-67xf-hhpq
quotingHave you ever wondered why #GrapheneOS has a separate PDF viewer?
nevent1q…e45h
Well that answer is pretty obvious, it is more secure to have a separate hardened, sandboxed utility designed for that instead of sharing such a responsibility with a much larger app with greater attack surface like a web browser or office suite. It is trivial for some threat actors to deliver weaponized, malicious PDF files to their targets.
If we know all of this, the next step for some may be to wonder "Why is the GrapheneOS PDF viewer secure?", for you, I will explain some of the most important details:
The GrapheneOS PDF Viewer app requires absolutely no user-facing permissions to run, it doesn't ask for any, nor does it need them. Without permissions the app is completely contained in the Android app sandbox and the security access model is far greater.
How the viewer opens a file is through making a false request to Localhost from the WebView and then intercepting that request with a stream of the PDF data. The benefits to this include:
1. We don't needing files access in the WebView (both setAllowFileAccess and setAllowContentAccess are set to false).
2. Allowing us to intercept headers into the request like CSP, Permissions Policy for hardening the sandboxing done via the WebView With CSP, all dynamic and inline CSS and JS is disabled. The only scripts loaded are those used for the viewer itself.
3. In addition to using WebView for PDF Viewer, Vanadium takes the place for the WebView on GrapheneOS, meaning GrapheneOS users take advantage of the exploit protections used in Vanadium.
Even with all of this, the PDF Viewer still has a fair amount of room for improvement when it comes to quality of life features and usability enhancements.