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

Issue 649239 link

Starred by 2 users

Issue metadata

Status: Verified
Owner:
Last visit > 30 days ago
Closed: Sep 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

Registration of service worker via <link> from sandboxed iframe dereferences nullptr

Project Member Reported by jww@chromium.org, Sep 22 2016

Issue description

If a sandboxed iframe attempts to register a service worker with <link rel=serviceworker>, it leads to a nullptr deference. The following will repro the case:

In main.html:
<iframe sandbox="allow-scripts" src="iframe.html"></iframe>

In iframe.html:
<script>
var link = document.createElement('link');
link.setAttribute('rel', 'serviceworker');
link.setAttribute('href', 'a-valid-service-worker.js');
document.getElementsByTagName('head')[0].appendChild(link);
</script>

The dereference happens in ServiceWorkerLinkResource::process(), which does not account for the possibility that NavigatorServiceWorker::serviceWorker can return a nullptr. It does so in this case because sandboxed iframes are not allowed to register service workers.

Notably a similar error occurs if you try to register a SW with a <link> from the experimental Suborigins feature as well.

I have a fix that I will upload shortly.
 
Project Member

Comment 1 by sheriffbot@chromium.org, Sep 22 2016

Labels: -Pri-3 Pri-2
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam -Security_Severity-Low Stability-Crash Restrict-View-Google Type-Bug
As far as I understand this report, the pointer is guaranteed to be null in the failing case, and thus this isn't exploitable beyond DoS.

Per Chrome Security Severity guidelines, DoS bugs are treated as stability issues only.

Comment 3 by jww@chromium.org, Sep 22 2016

Labels: -Restrict-View-Google
Good call, elawrence. I'm unrestricting completely. Seems like it should be a public bug.
Project Member

Comment 4 by bugdroid1@chromium.org, Sep 24 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2c0f1f71edd2ae034329ad2617e68fa89dbe536c

commit 2c0f1f71edd2ae034329ad2617e68fa89dbe536c
Author: jww <jww@chromium.org>
Date: Sat Sep 24 23:35:35 2016

Service worker creation from <link> leads to nullptr dereference

If a sandboxed iframe or a frame in a suborigin attempts to register a
service worker with <link rel=serviceworker>, it leads to a nullptr
deference. This is because ServiceWorkerLinkResource::process() does not
account for the possibility that NavigatorServiceWorker::serviceWorker
can return a nullptr. In this case, sandboxed iframes and suborigins are
not allowed to register service workers, so they return nullptr.

The solution is to check for nullptr and throw an appropriate error.
Tests are added to verify as well.

BUG= 649239 

Review-Url: https://codereview.chromium.org/2358993003
Cr-Commit-Position: refs/heads/master@{#420853}

[modify] https://crrev.com/2c0f1f71edd2ae034329ad2617e68fa89dbe536c/third_party/WebKit/LayoutTests/http/tests/security/suborigins/suborigin-service-worker-dom-access.php
[add] https://crrev.com/2c0f1f71edd2ae034329ad2617e68fa89dbe536c/third_party/WebKit/LayoutTests/http/tests/security/suborigins/suborigin-service-worker-link-rel.php
[add] https://crrev.com/2c0f1f71edd2ae034329ad2617e68fa89dbe536c/third_party/WebKit/LayoutTests/http/tests/serviceworker/resources/iframe-register-link-element.html
[add] https://crrev.com/2c0f1f71edd2ae034329ad2617e68fa89dbe536c/third_party/WebKit/LayoutTests/http/tests/serviceworker/sandbox-iframe-register-link-element.html
[modify] https://crrev.com/2c0f1f71edd2ae034329ad2617e68fa89dbe536c/third_party/WebKit/Source/modules/serviceworkers/NavigatorServiceWorker.cpp
[modify] https://crrev.com/2c0f1f71edd2ae034329ad2617e68fa89dbe536c/third_party/WebKit/Source/modules/serviceworkers/ServiceWorkerLinkResource.cpp

Comment 5 by jww@chromium.org, Sep 25 2016

Status: Verified (was: Assigned)

Comment 6 by falken@chromium.org, Sep 26 2016

Labels: M-55
Project Member

Comment 7 by bugdroid1@chromium.org, Sep 26 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8c8b27dda56ab54ec9028335ff0328aae0530feb

commit 8c8b27dda56ab54ec9028335ff0328aae0530feb
Author: jww <jww@chromium.org>
Date: Mon Sep 26 20:54:29 2016

Disable WebSockets API in suborigins

For v1 of the spec, the Suborigins spec disables WebSockets until it is
decided how the presence of a suborigin should be communicated. This CL
throws a JS SecurityException when the application tries to create a
WebSockets object from a suborigin.Added LayoutTest for exception

BUG= 649239 

Review-Url: https://codereview.chromium.org/2362263003
Cr-Commit-Position: refs/heads/master@{#420987}

[add] https://crrev.com/8c8b27dda56ab54ec9028335ff0328aae0530feb/third_party/WebKit/LayoutTests/http/tests/security/suborigins/suborigin-websocket.php
[modify] https://crrev.com/8c8b27dda56ab54ec9028335ff0328aae0530feb/third_party/WebKit/Source/modules/websockets/DOMWebSocket.cpp

Sign in to add a comment