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

Issue metadata

Status: Verified
Closed: Feb 2018
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 1
Type: Bug-Security

Blocked on:
issue 808334

Sign in to add a comment

Issue 808838: Security: Same origin bypass with Service Workers + PDF plugin

Reported by, Feb 4 2018 Project Member

Issue description

Service workers can be used to intercept same-origin requests and respond with a cross-origin response.
Chrome's built-in PDF viewer component allows web pages to read the content of same-origin PDF files.
An attacker can bypass this same origin policy by loading a remote PDF file via a same-origin URL that is intercepted via a Service Worker.

This bug is possibly caused by SW-unawareness of the mimeHandlerPrivate API (used by the PDF plugin).

Chrome Version: 64.0.3282.119 (stable) + 66.0.3339.0 (canary)

1. Visit
2. Observe that the page reads and shows the content of a PDF file at a different origin.

For future reference, I have attached the two files for the exploit.
Service Workers are only enabled on HTTPS, so these files must be served over HTTPS (if serving over localhost, use the --allow-insecure-localhost flag).
1.4 KB View Download
358 bytes View Download

Comment 1 by, Feb 4 2018

Components: Blink>ServiceWorker Blink>Network>FetchAPI
ccing raymes because he fixed  bug 520422  (not assigning because he seems OOO).

Comment 2 by, Feb 4 2018

Blockedon: 808334
Lots of interest in ServiceWorker this year.

Comment 3 by, Feb 4 2018

@#2 Can you cc me on issue 808334 ?

Comment 4 by, Feb 5 2018

Labels: Security_Severity-High Security_Impact-Stable
Status: Assigned (was: Untriaged)
falken@: Can you triage this?

Cross-origin reads feel "high" severity to me. Could be convinced it's "medium" since (I assume?) the exploit is limited to PDFs?

Comment 5 by, Feb 5 2018

Project Member
Labels: M-64

Comment 6 by, Feb 5 2018

Project Member
Labels: Pri-1

Comment 7 by, Feb 6 2018


Comment 8 by, Feb 6 2018

See also  issue 413094  and  issue 771933 .  I think requests from plugins/embed are supposed to skip the service worker.

Comment 9 by, Feb 12 2018

Status: Started (was: Assigned)
I've investigated this a bit more, and this is indeed an inssue in mimeHandlerPrivate.

There are two ways to solve this bug:
1. Propagate the actual URL of the response through the mimeHandlerPrivate API. That can be done by replacing "request->url()" with a look up for "response->head.url_list_via_service_worker" (and falling back to request->url() if needed).

2. Hiding the request from SW by calling request.SetServiceWorkerMode at the construction of the URLRequest in MimeHandlerViewContainer::OnReady

Since plugins requests are supposed to be hidden from SW, I have submitted a patch that implements the second idea:

Comment 10 by, Feb 13 2018


Comment 11 by, Feb 13 2018

Thanks Rob for taking this and investigating.

The solution proposed in #1 looks a bit scary: it's changing RDHI which could affect things beyond MimeHandler/PDF. The real solution there would probably involve plumbing ResourceResponseInfo::FetchResponseType to the delegate, so it knows whether the response is opaque or not. You could have a cross-origin, non-opaque response if CORS was enabled.

The solution proposed in #2 looks more palatable and simpler but it possibly breaks existing content on the web. Would you be able to see whether PDFs skip the service worker for Firefox/Edge/Safari? If so I think we could go ahead and just do #2.

Comment 12 by, Feb 14 2018

@#11 I opened the PoC from the report in Firefox, and did not see a PDF file.
Additionally, I visited about:debugging in Firefox, switched to the Worker tab, launched the debugger and put a breakpoint inside the "fetch" event and upon refreshing the page, it was triggered once (for the HTML page, not for the embedded PDF).

I haven't tested Safari nor Edge, but since plugin requests are expected to bypass the SW (mentioned twice in the spec, at [1] and [2]), I don't expect compat issues.

In my patch I provided an implementation-specific regression test; while it is possible to write a WPT test (based on my PoC), I don't think that is really useful, because there is no guarantee that the implementation is able to render the application/pdf MIME type. With my implementation-specific test, I do not only verify that the SW cannot observe plugin requests, I also verify that the plugin is actually loaded.

Can anyone with access to bug 808334 cc me there? It is marked as a blocker for this bug, but without access I cannot judge whether it should be.


Comment 13 by, Feb 14 2018

Thanks, that all makes sense. The service worker spec and impls evolved in parallel over the years and often there is a mismatch, so it's good to have confirmation that at least Firefox is matching.

bug 808334 isn't really a blocker, it's a tracking meta bug for this class of bug (service worker allows cross-origin access).

Comment 14 by, Feb 16 2018

Project Member
The following revision refers to this bug:

commit e89b9003df8c7bd7822e5b6c0a76e726a6ed1505
Author: Rob Wu <>
Date: Fri Feb 16 19:46:08 2018

Skip Service workers in requests for mime handler plugins

BUG= 808838 
TEST=./browser_tests --gtest_filter=*/ServiceWorkerTest.MimeHandlerView*

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_mojo
Change-Id: I82e75c200091babbab648a04232db47e2938d914
Commit-Queue: Rob Wu <>
Reviewed-by: Istiaque Ahmed <>
Reviewed-by: Matt Falkenhagen <>
Cr-Commit-Position: refs/heads/master@{#537386}

Comment 15 by, Feb 17 2018

Labels: Merge-Request-65
Status: Verified (was: Started)
Verified fixed in 66.0.3351.0 using the STR from the report.
When I look in the console, I see the following error that indicates that the request was not intercepted by the Service Worker, but handled directly by the server instead:

GET 404 (Not Found)

Merge request for e89b9003df8c7bd7822e5b6c0a76e726a6ed1505. The fix itself is a single line of code, the rest of the commit are unit tests and comments.

Comment 16 by, Feb 17 2018

Project Member
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify

Comment 17 by, Feb 17 2018

Project Member
Labels: -Merge-Request-65 Merge-Review-65 Hotlist-Merge-Review
This bug requires manual review: M65 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit - Your friendly Sheriffbot

Comment 18 by, Feb 17 2018

awhalley@ (Security TPM) for M65 merge review.

Comment 19 by, Feb 19 2018

It might make sense to wait for M66, so this change and the others disabling EMBED/OBJECT requests ( and will all be together in 66 and we can make a entry saying we've done this, as it's conceivable it can break web content (I still think we should make the change and taking the risk, just not sure we need to put it in 65).

I've reached out to a Blink API owner for their thoughts.

Comment 20 by, Feb 19 2018

M65 is very close to Stable promotion and we're only taking truly critical and safe merges in. So if this can wait for M66 will be great.

Comment 21 by, Feb 19 2018

Labels: reward-topanel

Comment 22 by, Feb 20 2018

Labels: -M-64 -Merge-Review-65 M-66 Merge-Rejected-65
Thanks falken@ - let's wait until 66.

Comment 23 by, Feb 26 2018

Labels: -reward-topanel reward-unpaid reward-4500
*** Boilerplate reminders! ***
Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.

Comment 24 by, Feb 26 2018

Nice one Rob, the VRP Panel decided to award $4,500 for this report.

Comment 25 by, Feb 27 2018

Labels: -reward-unpaid reward-inprocess

Comment 26 by, Apr 17 2018

Labels: Release-0-M66

Comment 27 by, Apr 25 2018

Labels: CVE-2018-6089

Comment 28 by, Apr 25 2018

Labels: CVE_description-missing

Comment 29 by, May 26 2018

Project Member
Labels: -Restrict-View-SecurityNotify allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot

Comment 30 by, Dec 4

Labels: -CVE_description-missing CVE_description-submitted

Sign in to add a comment