Probably an ASLR bypass (infoleak) at a minimum.

+georgesak, since it looks like some of this was added in  issue 457527  and  issue 621070 .  Agreed that we should not have chrome:// URLs that take actions based on URL parameters, which becomes much easier to exploit without control over the process.

Does someone know more about how this page works and how we could switch it to a more typical WebUI pattern?

Also, combined with  issue 736876  (where web pages are found to share a process with chrome://discards), this means an exploited renderer can cause any tab to be discarded.

Potentially chainable with https://bugs.chromium.org/p/chromium/issues/detail?id=736876

Not sure if it impacts Stable. nick@, are you testing this with canary build?

FWIW, the code that starts executing various actions based on the navigation is at [1]. Looking a bit closer chrome://discards is not a WebUI page on its own (not backed up by a WebUIMessageHandler). It lives within about_ui.cc WebUIController, which is an umbrella controller spawned for various chrome:// pages (see [2]).


[1] https://cs.chromium.org/chromium/src/chrome/browser/ui/webui/about_ui.cc?type=cs&l=706. 
[2] https://cs.chromium.org/chromium/src/chrome/browser/ui/webui/chrome_web_ui_controller_factory.cc?type=cs&q=AboutUI&l=288

This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

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

The code was moved into TabManager as part of a refactor of existing ChromeOS code. The security issue has existed since the feature was originally added, here:

https://chromium.googlesource.com/chromium/src/+/de9621738c1289655aedc19469ed168cdb742bb2

Never having really worked on internal chrome:// pages, what is the recommended way to do this? Have an example to share?

Have you come across https://chromium.googlesource.com/chromium/src/+/master/docs/webui_explainer.md ?

isn't the real bug that IDs are generated from pointers?  that's spooky.

also, yes: it seems fairly feasible to just set up a WebUI object and a default (HTML) resource with $i18n{} tags in it (or populated via JavaScript) rather than this "I'm an about handler" business that chrome://discards currently does.  Then, rather than navigate to a URL (i.e. /run/<id>) there should be something like

link.onclick = function() {
  chrome.send('discardTab', [tabId]);
};

in JS.  This is basically how other pages work.

Thanks for the pointers. I'll try to find someone on the team to grab this.

chrisha: 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

chrisha: Uh oh! This issue still open and hasn't been updated in the last 29 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

We commit ourselves to a 60 day deadline for fixing for high severity vulnerabilities, and have exceeded it here. If you're unable to look into this soon, could you please find another owner or remove yourself so that this gets back into the security triage queue?

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

crisha: This is marked as high severity but hasn't had any activity for a few months. Are you able to help find someone to investigate this issue? Thanks!

chrisha: friendly ping. this is a high severity issue that should be fixed quickly. please help triage this.

Sorry, this is extremely low priority for us as it is an informational page. The impact is limited to an exploited renderer being able to cause a tab to be unloaded, forcing a reload. There is a minor potential for data loss, but no privacy impact. I'd argue that this isn't a high severity bug. Agreed that it does need to be fixed, but we don't have the resources to focus on this for a while.

chrisha@: Nick and I respectfully disagree with your conclusion.  Here's why:

1) The page gives the ability to duplicate and discard arbitrary WebContents objects in the browser, which can give an attacker some amount of control over a significant portion of browser heap memory (as a stepping stone towards exploiting UaFs, for example).  For example, repeated discards may allow them to try again if an exploit doesn't work the first time, making it more reliable.

2) The information itself, if leaked to a malicious page through another bug, consists of many WebContents pointers, including WebContents under the attacker's control (e.g., via window.open).  This could help with ALSR bypasses.

3) The code in about_ui.cc for handling these URLs are providing a bad example for others to copy/paste, since WebUI pages should never be taking action based on input from the URL.

It's possible that this is Medium rather than High severity due to the need for other bugs to exploit it, but it's still a serious issue.

Given the helpful comments on this bug from the WebUI folks, it seems like it would not take a significant effort to refactor the page to use a safer approach.  It also appears the page has been gaining features more recently than this bug was filed (e.g., fmeawad's r488273), so it's getting some attention already.

Given that WebUI pages are the highest privilege surface in Chrome, we're trying to wrap up the security bugs that we know exist in this space.  Please help us by finding an owner.  Thanks!

I'm currently refactoring the discarding code https://crbug.com/775644. As part of this refactoring, WebContents pointers will no longer be used to discard tabs. Instead, we'll used indices.

Discarding tabs by calling chrome.send('discardTab', [tabId]); instead of by navigating to a chrome://discards/run/ URL would also be a useful improvement.

Thank you fdoray! Will you also be working on removing the navigating to chrome://discards/run aspect too, or will that problem remain even after resolving Issue 775644?

I do think this is a Medium, not a High (mitigated by the need for other bugs to exist first).

It's not good for us to let bugs that we reasonably thought were High live this long, way past our 60-day deadline for Highs. In the future, if you can't prioritize an incoming High bug, please work with us to find someone who can. Thank you!

I'm going to keep this at Pri-1, given its age. Let's just knock this one out. :)

I've got another CL underway that reworks the chrome://discards UX to use Mojo Web UI.

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

commit c4453edb44d204b77378b3f885849d67fcdca3c0
Author: Chris Hamilton <chrisha@chromium.org>
Date: Wed Nov 22 16:23:17 2017

Port existing chrome://discards to new WebUI.

This gets rid of a long-standing security bug.

BUG= 736882 

Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I51caab189a36efdc940cb03384c50d0beb79b42d
Reviewed-on: https://chromium-review.googlesource.com/761996
Commit-Queue: Chris Hamilton <chrisha@chromium.org>
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: François Doray <fdoray@chromium.org>
Reviewed-by: Will Harris <wfh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#518650}
[modify] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/BUILD.gn
[modify] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/browser_resources.grd
[modify] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/chrome_content_browser_manifest_overlay.json
[modify] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/resource_coordinator/tab_manager.cc
[modify] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/resource_coordinator/tab_manager.h
[modify] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/resource_coordinator/tab_manager_delegate_chromeos.cc
[modify] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/resource_coordinator/tab_manager_delegate_chromeos_unittest.cc
[modify] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/resource_coordinator/tab_manager_unittest.cc
[modify] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/resource_coordinator/tab_manager_web_contents_data.cc
[modify] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/resource_coordinator/tab_manager_web_contents_data.h
[modify] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/resource_coordinator/tab_manager_web_contents_data_unittest.cc
[modify] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/resource_coordinator/tab_stats.h
[add] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/resources/discards/.eslintrc.js
[add] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/resources/discards/OWNERS
[add] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/resources/discards/discards.css
[add] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/resources/discards/discards.html
[add] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/resources/discards/discards.js
[modify] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/ui/BUILD.gn
[modify] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/ui/webui/about_ui.cc
[modify] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/ui/webui/chrome_web_ui_controller_factory.cc
[add] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/ui/webui/discards/BUILD.gn
[add] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/ui/webui/discards/OWNERS
[add] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/ui/webui/discards/discards.mojom
[add] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/ui/webui/discards/discards_ui.cc
[add] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/browser/ui/webui/discards/discards_ui.h
[modify] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/common/webui_url_constants.cc
[modify] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/test/data/webui/BUILD.gn
[add] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/test/data/webui/discards/OWNERS
[add] https://crrev.com/c4453edb44d204b77378b3f885849d67fcdca3c0/chrome/test/data/webui/discards/discards_browsertest.js

chrisha@: This can be marked fixed after your r518650, correct?  (Thanks for rewriting it!)

Indeed it can, forgot to update this bug!

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