New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 915398 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jan 14
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Feature

Blocked on:
issue 915721
issue 918060



Sign in to add a comment

Stealing PDF content by changing renderer's security_origin_

Reported by jun.koka...@microsoft.com, Dec 15

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce the problem:
1. Go to https://tt.shhnjk.com/steal_pdf.html
2. Open Windbg and attach to that process
3. Download spoof.js attached and run ".scriptrun C:\windbg\spoof.js"
4. Click "Go" button on the Web Page

What is the expected behavior?
PDF content of www.apple.com should be leaked to tt.shhnjk.com

What went wrong?
PDF Script API allows postMessages from Javascript. To avoid information leakage, it checks if message source's origin is same as PDF's. Unfortunately, security_origin_ in renderer process can be modified once renderer process is compromised. This is not a big deal right now since there's no Site Isolation applied to PDF processes. But this bug should be tracked as part of issue 786673

Did this work before? N/A 

Chrome version: 71.0.3578.98  Channel: stable
OS Version: 10.0
Flash Version:
 
spoof.js
1.5 KB View Download
Attaching PoC.
Just confirmed that this works with chrome://flags/#pdf-isolation enabled.
PoC.html
522 bytes View Download
Cc: creis@chromium.org nasko@chromium.org
Components: Internals>Plugins>PDF Internals>Sandbox>SiteIsolation
Labels: Security_Severity-Medium M-71 Security_Impact-Stable
Owner: lukasza@chromium.org
Status: Assigned (was: Unconfirmed)
Passing over to Site isolation folks to further decide who should own this/whether it should be a separate security bug or is already tracked by site isolation. Assigning it security medium tentatively.
Project Member

Comment 3 by sheriffbot@chromium.org, Dec 17

Labels: -Pri-2 Pri-1
Cc: tsepez@chromium.org
+tsepez@ who AFAIR worked on PDF isolation

I have trouble identifying where "checks if message source's origin is same as PDF's" are happening.  I don't see such checks in OutOfProcessInstance::HandleMessage (where getSelectedTextReply is sent in response to kJSGetSelectedTextType).  I also don't see an explicit origin field in the PpapiHostMsg_PPBInstance_PostMessage IPC (which AFAIU is sent directly from the rendererer which embeds the plugin into the plugin host process).

FWIW, I believe a similar bug might be present in window.postMessage (I've opened  issue 915721  to track this).
Given that it is known that Site Isolation doesn't yet protect against compromised renderers, I think this should be tracked as a regular, non-security bug and/or feature work.  What do you all think?
>I have trouble identifying where "checks if message source's origin is same as PDF's" are happening.

Following is the check.
https://cs.chromium.org/chromium/src/chrome/browser/resources/pdf/pdf_viewer.js?q=getSelectedTextReply&sq=package:chromium&g=0&l=856
Blockedon: 918060
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam -Security_Impact-Stable -Security_Severity-Medium Type-Feature
Give lack of responses to #c5 above, let me open this bug up.
Blockedon: 915721
Labels: -Pri-1 Pri-2
Cc: awhalley@google.com
Labels: reward-topanel rewa
Even though this is not a security *bug* (but rather part of feature work for Site Isolation enforcements), I think that we should still consider this bug for VRP, given that we were not aware of these particular gaps.
Labels: -rewa
Status: Fixed (was: Assigned)
I think the attack should be prevented now (after r621839 and r622165).

Sign in to add a comment