Page MenuHomePhabricator

External reference in PDF
Closed, ResolvedPublic

Description

FINDING ID: iSEC-WMF1214-15

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

DESCRIPTION: PDF files can contain references to external content, such as images, audio, and video.
Loading external content from a PDF can be used to de-anonymize users who view the PDF directly
using Adobe Reader or another PDF reader.

EXPLOIT SCENARIO: An attacker wishes to determine who reads a specific wiki article. The attacker
creates a PDF that loads content from 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's server, 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 created this task.Feb 17 2015, 7:09 PM
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: 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.
csteipp added subscribers: matmarex, Aklapper, Parent5446, csteipp.
csteipp added a subscriber: bd808.Feb 17 2015, 8:05 PM

Example pdf:

This doesn't appear to make an external call in either Chrome or Firefox's built-in readers, but lots of readers are stuck with Adobe Reader.

A small warning somewhere on the page seems like it would be sufficient, instead of a full click-through as iSec suggested. Maybe @bd808 can give some product input, or @Tgr, is there anyone in multimedia who would be good to look at this?

csteipp added a subscriber: Tgr.Feb 17 2015, 8:06 PM
Tgr added a comment.EditedFeb 17 2015, 8:47 PM

I don't think there is any way to place a warning that could not be worked around by e.g. a Media: link, unless we show a clickthrough before direct access to the file, which would raise many technical and UX problems. The severity of the issue does not justify that IMO.

We could show a warning on the file description page, more as a way to educate users than to prevent exploits. Would be nice if we could point them to reliable information about how to avoid / which PDF readers are safe.

The Acrobat manual claims that users are warned before accessing external resources; not sure about Reader.

bd808 added a comment.Feb 17 2015, 8:53 PM

A small warning somewhere on the page seems like it would be sufficient, instead of a full click-through as iSec suggested. Maybe @bd808 can give some product input, or @Tgr, is there anyone in multimedia who would be good to look at this?

Could we just have a smallish warning banner on all PDF File: pages or is something needed in articles directly? I think Acrobat Reader lets security conscious users block web access already [ 0 ]. I get the possible reflection attack but introducing a full interstitial for all PDF documents seems extreme. I may not be paranoid enough though. In the modern web with Google, Twitter and Pintrest tracking bugs on practically every content page that isn't in the Wikimedia family has reduced my sense that a reasonable user should infer that they have privacy when using the Internet unless they are personally taking precautions to eliminate such everyday interactions.

Tgr added a comment.Feb 17 2015, 8:56 PM

As for the long-term solution, we already convert PDF to static images via ghostscript + imagemagick.

In T89744#1044727, @Tgr wrote:

I don't think there is any way to place a warning that could not be worked around by e.g. a Media: link, unless we show a clickthrough before direct access to the file, which would raise many technical and UX problems. The severity of the issue does not justify that IMO.

Totally agree.

We could show a warning on the file description page, more as a way to educate users than to prevent exploits. Would be nice if we could point them to reliable information about how to avoid / which PDF readers are safe.
The Acrobat manual claims that users are warned before accessing external resources; not sure about Reader.

I'll try to dig up a copy of Reader to see exactly how it's currently working. If it's warning users, then I don't think we need to. If there are enough ways to get it to load external resources without prompting the user, then a warning on the file page should be fine.

I'll try to dig up a copy of Reader to see exactly how it's currently working. If it's warning users, then I don't think we need to. If there are enough ways to get it to load external resources without prompting the user, then a warning on the file page should be fine.

It looks like the default behavior for Acrobat Reader on Windows is to always pop up a browser with the external site.

I think we have enough Windows/IE readers that it warrants a message, although the impact is low enough that if we're planning to fix T89765 publicly in the near future, I don't think it's worth holding up the next security release. @Tgr, do you think T89765 is likely to get done?

csteipp added a subscriber: Gilles.Feb 18 2015, 8:07 PM

Adding @Gilles for context on T89765

csteipp closed this task as Resolved.Apr 20 2015, 5:20 PM

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.
TTO added a subscriber: TTO.Sep 20 2015, 6:26 AM

It looks like the default behavior for Acrobat Reader on Windows is to always pop up a browser with the external site.

@csteipp: Could you clarify this?

Apparently this comment was used as the basis for the statement at https://www.mediawiki.org/wiki/Help:Security/PDF_files that Adobe Acrobat, with its default settings, is NOT safe. As I commented at the talk page, if we're going to make such scathing statements we should at least take the time to explain them in more detail. What exactly is meant by "safe"?

As far as I can tell, my installation of Adobe Reader XI on Windows prompts me upon opening the "launchURL.pdf" document. Is that what we're talking about here?

sbassett triaged this task as Medium priority.Oct 16 2019, 5:35 PM
sbassett moved this task from Backlog to Done on the Privacy board.