sadrul@, as an OWNER for ui/views, could you please help to triage this?

Redirecting to a website_settings owner for triage.

benwells: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Punting to lgarron who owns the website settings dialog.

Also cc'ing Dom who may have fixed this / something similar recently.

My 2 cents after a 5 second look: unless there's a strong reason for it not to be, WebsiteSettings should be a WebContentsObserver, so it can be properly informed when its owning WebContents is gone.

Alternatively, the callsite in WebsiteSettingsPopupView (which is a WebContentsObserver) can check web_contents() and not call presenter_->OnUIClosing() if the WebContents is gone or in the process of being destroyed.

lgarron: Uh oh! This issue still open and hasn't been updated in the last 28 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I took a longer look at this, and the answer is to definitely make WebsiteSettings a WebContentsObserver. The UaF is directly because the underlying WebContents has been freed at shutdown, but the UI closing has occurred afterwards with WebsiteSettings still holding a raw pointer. Putting up a CL now.

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

commit bdd53b5fbfbbb32d6ec8e5d8107040f3fa779868
Author: dominickn <dominickn@chromium.org>
Date: Wed Sep 28 01:08:13 2016

Fix a use-after-free in WebsiteSettings::OnUIClosing.

This CL makes WebsiteSettings a WebContentsObserver, fixing a
use-after-free/race at browser shutdown. The exploit triggers when UI
destruction occurs after the WebContents that WebsiteSettings holds a
pointer to has been freed by the TabStripModel, triggering a deref of
the now invalid pointer.

WebsiteSettings now uses its inherited web_contents() method, which
will return a nullptr after the contents is freed. This prevents the
use-after-free.

BUG= 640571 

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

[modify] https://crrev.com/bdd53b5fbfbbb32d6ec8e5d8107040f3fa779868/chrome/browser/ui/website_settings/website_settings.cc
[modify] https://crrev.com/bdd53b5fbfbbb32d6ec8e5d8107040f3fa779868/chrome/browser/ui/website_settings/website_settings.h

ClusterFuzz has detected this issue as fixed in range 421240:421437.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=5128007922745344

Fuzzer: attekett_surku_fuzzer
Job Type: linux_lsan_chrome_mp
Platform Id: linux

Crash Type: Heap-use-after-free READ 8
Crash Address: 0x61b0000793a0
Crash State:
  WebsiteSettings::OnUIClosing
  views::Widget::OnNativeWidgetDestroying
  views::NativeWidgetAura::OnWindowDestroying
  
Recommended Security Severity: High

Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_lsan_chrome_mp&range=381674:381687
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_lsan_chrome_mp&range=421240:421437

Unminimized Testcase: https://cluster-fuzz.appspot.com/download/AMIfv968FL30SAAzSSyu6iNWavJNFOw0TPOawd07Vk2EB9vmk_cuujhr2Av9NaeN4BRvjB2kM_BGLwvoETtvWtQ0iOj3jabWH4Z097zS1Od7NKdFHA4z64WQ0xTXUJs0caRPCnT3_7aJgkIyiU6aG9GQ4Hg2eSIqNJ1V_05cDfG6DgwsbQLfcr0?testcase_id=5128007922745344


Additional requirements: Requires Gestures

See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

If ClusterFuzz says so, it must be so!

I'm afraid the panel declined to reward for this bug, due to the mitigations of requiring user gesture and triggering at shutdown.

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