Page MenuHomePhabricator

Stored XSS in PDF files
Closed, ResolvedPublic



TARGETS: The upload feature, available at http://devwiki/wiki/Special:Upload .

DESCRIPTION: The PDF format allows for documents containing embedded JavaScript. During testing,
a PDF that executes JavaScript when the document is opened was successfully uploaded.
Testing indicated that this feature only works in Adobe Reader, whereas other readers such as the PDF
reader built into Firefox and the PDF reader built into Chrome do not support JavaScript actions.
JavaScript could be used to de-anonymize a user or to attempt exploits against a user. PDF readers
execute embedded JavaScript in a sandboxed context that should not have any ability to access data
from the wiki domain.

EXPLOIT SCENARIO: An attacker wishes to determine who reads a specific wiki article. The attacker
creates a PDF that uses JavaScript to make surreptitious HTTP requests to an attacker-controlled server,
using an existing PDF document related to the article as a base. A user interested in the topic opens
the PDF for more information while reading the article and their PDF reader sends a request to the
attacker, revealing their IP address, and by extension, their location.

SHORT TERM SOLUTION: Provide a click-through warning informing users that PDF documents are
active content that could potentially de-anonymize them when viewed directly.

LONG TERM SOLUTION: Convert uploaded PDFs to static images to avoid issues with active content.
Ensure the library used for conversion is robust as it will be parsing potentially malicious content on
the server side, which could be a greater compromise than individual users. Consider setting up a
sandboxed environment.

Event Timeline

csteipp claimed this task.
csteipp raised the priority of this task from to Needs Triage.
csteipp updated the task description. (Show Details)
csteipp added a project: acl*security.
csteipp changed the visibility from "Public (No Login Required)" to "Custom Policy".
csteipp changed the edit policy from "All Users" to "Custom Policy".
csteipp changed Security from None to Software security bug.

This blogpost mentions some tools for detecting JS in PDF (pdftk and jsunpack) but they don't look automation-friendly. There are a bunch of security papers about detecting malicious Javascript in PDF files, but they focus on differentiating malicious and non-malicious code so they are usually rather complex (honeypot/sandbox environments or static analysis with some sort of machine learning) and not really useful for us. looks the most promising so far.

A nice collection of PDF analyzer tools here.

Apparently the PDF format offers a lot of options for obfuscating contents (see e.g. this post). There doesn't seem to be a good way to even tell if a PDF file contains Javascript.

Fixed by T89765, which is in production, so closing this. If we want to backport this to 1.23/24, Release-Engineering-Team can reopen. But I don't think we're going to have strong demand for this by third party users.

csteipp changed the visibility from "Custom Policy" to "Public (No Login Required)".Apr 20 2015, 5:21 PM
csteipp changed the edit policy from "Custom Policy" to "All Users".
csteipp changed Security from Software security bug to None.