This does indeed look a lot like  issue 528505  but given the user specifically has to right click then "open in new tab" I'm inclined to give this a lower severity though.

I can repro on stable 53 and canary 55.

-> paulmeyer who landed a previous fix to this.

paulmeyer: Ping. Can this use the same fixes implemented for 528505?

I'll have to look into this more. Right now I don't even know how this is working in print preview, when it is blocked in a regular PDF.

Okay, so now I know where these permissions are being granted:

1) Because print preview is at chrome://print/, it automatically gets access to all URLs in its own scheme (chrome://) in ChildProcessSecurityPolicyImpl::GrantRequestURL().

2) Because print preview is WebUI, it automatically gets access to all chrome:// and file:// URLs in ChildProcessSecurityPolicyImpl::GrantWebUIBindings().

Both of these mechanisms would need to be altered in order to prevent access to chrome:// URLs from print preview. It is possible that I can utilize my addition of origin-based permissions (from the last bug) to fix this. For example:

1) I could grant access only to the specific requested origin in GrantRequestURL() rather than the whole scheme.

2) I could grant access to a whitelist of chrome:// origins (like chrome://resources/ and chrome://theme/) rather than granting access to all of chrome:// in GrantWebUIBindings().

I think this could fix this bug, but I am also worried that these changes might break other things.

Adding nick@, who also has done work on ChildProcessSecurityPolicy and granting access to resources.

Thanks for finding this!  This looks very concerning, and we should definitely find a way to restrict it.

thestig@: What are the reasons print preview uses WebUI and a chrome:// scheme?  We should make sure we aren't loading untrusted content directly into a privileged context.  I'm concerned what else the print preview could do if it took over the renderer process.

I'm not saying this is the way to fix this, but I figured I'd ask: why do links even need to be active in a print preview?

Actually, I don't think I should change the permissions granted to WebUI in general, because I think it does make sense for WebUI to access anything in chrome://. I think the real problem here is that the preview is treated as WebUI at all.

Based on what weili@ mentioned in a discussion yesterday, it seems the actual PDF itself is rendered in a PPAPI process, which should not have WebUI bindings. Based on some other bugs from the past, I think the problem is that the link click generates a navigate event, which is then handled in the PPAPI embedder, which actually does have WebUI permissions (to draw the UI at least).

I think stubbing the navigation calls from the PDF plugin in the print preview WebUI wrapper should be a straightforward solution to making links do nothing in that mode. I don't see a good reason why clicking on links inside print preview should work.

Agree with what nasko@ said. What is even better is that we don't even make links clickable in print preview. It is just for preview, not for navigation/interaction, right? I think this should be a fair assumption. 

If so, I can look into how to fix this way.

BTW, for pdf files with links inside, we don't have those links clickable in print preview, which seems fine/good. :) Anyone interested can try the attached file.

Deleted: tryme.pdf 45.8 KB

tryme.pdf 45.8 KB Download

We shouldn't follow any link in Print Preview. This is important to fix. DOn't even pass any callback to the engine.

Dan, can you please take a look, this might be a simple fix.

thestig@ is this a quick change in PDFiumEngine?

I can take this.

This is actually already fixed by rbpotter@. See  crbug.com/699000 . Tested with the original repro steps, and with the .pdf provided by weili@ on #14. In print preview, the links in both cases are already not active.

Not duping as this is marked as a security bug.

I'm afraid the VRP panel declined to reward for this report, given the amount of user interaction required.

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