New issue
Advanced search Search tips
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

Security: Same origin bypass with Service Workers + PDF plugin

Project Member Reported by, Feb 4 2018

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).
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?
Project Member

Comment 5 by, Feb 5 2018

Labels: M-64
Project Member

Comment 6 by, Feb 5 2018

Labels: Pri-1
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

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.

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).
Project Member

Comment 14 by, Feb 16 2018

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.
Project Member

Comment 16 by, Feb 17 2018

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

Comment 17 by, Feb 17 2018

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
 awhalley@ (Security TPM) for M65 merge review.
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.
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.
Labels: reward-topanel
Labels: -M-64 -Merge-Review-65 M-66 Merge-Rejected-65
Thanks falken@ - let's wait until 66.
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.
Nice one Rob, the VRP Panel decided to award $4,500 for this report.
Labels: -reward-unpaid reward-inprocess
Labels: Release-0-M66
Labels: CVE-2018-6089
Labels: CVE_description-missing
Project Member

Comment 29 by, May 26

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

Sign in to add a comment