can you supply the source for these two PDF files please?

I'm assuming that the content of the PDF would not be readable back even by script, or can you demonstrate that? Until then, I think this sounds like a Low

I used the PDF generator from Thinkst to create tokens. I do not have the actual source, but this is what triggers the bug:

16 0 <</S/URI/URI(file:///etc/passwd)>>

I cannot read back the contents. 

Deleted: pdfgen.py 2.5 KB

pdfgen.py 2.5 KB View Download

Deleted: template.pdf 5.0 KB

template.pdf 5.0 KB Download

'To create tokens' I mean to create the PDFs of course.

Using mutool (mupdf-tools) it is possible to decompress the PDF streams, and still have a valid PDF. 

mutool clean -d readpasswd.pdf out.pdf

You can open it in a text editor and change the URI element directly (line 135). The decompressed file is attached!

Deleted: decompressed.pdf 4.7 KB

decompressed.pdf 4.7 KB Download

That is WAI, there is an "AA" entry (additional action) with trigger "O" (triggers when page is open), that causes opening the URL. This does seem fishy, though if the user has already opened a compromised pdf, they might as well open an evil url.

Options:
- Ignore this.
- Disable page open additional actions (I don't know of use cases for that, has anyone run into that?)
- Disable opening URLs except for links

Tom, WDYT?

Yea, seems like we should only honor web-safe resources.

So should we block file:// and chrome://, but not http(s):// ?

nasko@, perhaps you have a perspective here, for the PDF Viewer and plugins in general?

Adding creis@ and alexmos@ for input, as I'm out of office this week.

Hi all, any updates on the status of this issue?

This got fixed with https://pdfium-review.googlesource.com/c/pdfium/+/43410 which prevents URI additional actions that require no user interaction.

What is left for this but is to block URIs like file:// and chrome:// for links the user needs to click on.

Found this:

https://cs.chromium.org/chromium/src/chrome/browser/resources/pdf/navigator.js?l=185&rcl=a9c450d1237c78cfcf93603697c9972f7adf5187

This restricts navigation to URIs with the schemes: http, https, ftp, and file, plus mailto. In special, the file scheme is only accepted if we looking at a local file already.

WDYT, should we keep the restriction as it is or make it stronger and disallow navigation to files regardless?

If navigating to a file:// URL now requires (1) starting from a file:// PDF and (2) a user interaction, and if navigating to a chrome:// URL is not allowed, then this sounds fixed to me.  That would be on par with file:// HTML pages, which are allowed to link to other file:// URLs.

(That also sounds the expected outcome of the fixes for  issue 654279  and  issue 533520 .)

Great, marking as fixed then.

Hi vincentrr91@ - I'm afraid the VRP panel declined to award for this, as they deemed it to be a dupe of  issue 851821  that was reported just a little before this one. Still, many thanks!

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot