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 2 users
Status: Verified
Owner:
OOO until January 2
Closed: Mar 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security



Sign in to add a comment
Security: Don't let a normal web renderer navigate to a privileged URL
Project Member Reported by creis@chromium.org, Mar 8 2012 Back to list
 Issue 117230  showed a case that a normal web renderer was able to navigate to chrome://net-internals and chrome://downloads.  We have logic in RenderViewHost::FilterURL that looks for reports that a renderer navigated somewhere it shouldn't have, so we should add a check for this WebUI case, as well as other privileged URLs like extensions and apps.
 
Labels: SecImpacts-Stable SecImpacts-Beta SecSeverity-High Mstone-18
Milestone can be bumped up later if we decide to not merge to m18. Keeping m18 for now.
Comment 2 by creis@chromium.org, Mar 8 2012
Cc: tsepez@chromium.org jam@chromium.org
Status: Started
Actually, this looks like it was fixed by tsepez in M19:
http://codereview.chromium.org/8588039/diff/45001/content/browser/child_process_security_policy.cc

Before, we always returned true from ChildProcessSecurityPolicy::canRequestURL for chrome: URLs, because we thought they wouldn't be handled by the browser.  Now we realize they will be handled and do the proper SecurityStateMap check.

My only remaining concern is that we check for chrome: URLs in the ChromeContentBrowserClient, rather than in the content module.  The content module knows about WebUI, so content_shell would still be vulnerable.  Should we split this IsHandledURL between content and chrome?
Comment 3 by creis@chromium.org, Mar 8 2012
For reference, that fix is part of  issue 104466 .
Labels: -SecSeverity-High SecSeverity-Medium Merge-Approved
Status: FixUnreleased
If necessary, we can extract a small part of Tom's referenced change for merge purposes.

This hardening measure breaks one link in the chain of PinkiePie's Pwnium exploit.
Charlie, if you think it's important to fix content_shell, we should probably file a new, separate functional bug (probably without any security severity).
Comment 6 by creis@chromium.org, Mar 15 2012
Yes, my fix for content_shell would rely on the big patch I just landed for  issue 113496 , so we wouldn't be merging that anyway.  I'll file a bug for it.

It's worth noting that this fix apparently would have blocked both Sergey's and PinkiePie's exploits.  I originally filed in the context of Sergey's exploit, since he was able to make a normal renderer navigate to chrome://net-internals.  Because we didn't catch it in FilterURL, he had a chance to use another bug ( issue 117418 ) to acquire WebUI bindings.
Comment 7 by creis@chromium.org, Mar 15 2012
Filed  issue 118495  for content_shell.
Given that this would have stopped both Pwnium exploits, we should stay alert and eventually see if we need to merge something back to 17.
I understand how it would have stopped PinkiePie's, because it's rather obvious :) Which part of Sergey's would it have stopped?

Anyway, we might learn that M18 is saved today, in which case I can try and get it into the first M18.
Comment 10 by creis@chromium.org, Mar 19 2012
I described a bit of how it affected Sergey's exploit in comment 6.  His exploit navigated a page in a normal renderer to chrome://net-internals, which did not immediately receive WebUI bindings.  However, the URL was committed to history (which this fix would have stopped).  Thus, he was able to navigate away and then use history.back() to grant WebUI bindings to the process.  (That was fixed in  issue 117418 .)

Both of these bugs (along with others) were necessary for the exploit to get through.
Project Member Comment 11 by bugdroid1@chromium.org, Mar 20 2012
Labels: merge-merged-963
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=127838

------------------------------------------------------------------------
r127838 | cevans@chromium.org | Tue Mar 20 16:48:52 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/963/src/content/browser/child_process_security_policy.cc?r1=127838&r2=127837&pathrev=127838
 M http://src.chromium.org/viewvc/chrome/branches/963/src/content/browser/mock_content_browser_client.cc?r1=127838&r2=127837&pathrev=127838
 M http://src.chromium.org/viewvc/chrome/branches/963/src/content/public/browser/content_browser_client.h?r1=127838&r2=127837&pathrev=127838
 M http://src.chromium.org/viewvc/chrome/branches/963/src/content/browser/mock_content_browser_client.h?r1=127838&r2=127837&pathrev=127838
 M http://src.chromium.org/viewvc/chrome/branches/963/src/content/browser/renderer_host/render_view_host.cc?r1=127838&r2=127837&pathrev=127838
 M http://src.chromium.org/viewvc/chrome/branches/963/src/chrome/browser/chrome_content_browser_client.cc?r1=127838&r2=127837&pathrev=127838
 M http://src.chromium.org/viewvc/chrome/branches/963/src/content/shell/shell_content_browser_client.h?r1=127838&r2=127837&pathrev=127838
 M http://src.chromium.org/viewvc/chrome/branches/963/src/content/shell/shell_content_browser_client.cc?r1=127838&r2=127837&pathrev=127838
 M http://src.chromium.org/viewvc/chrome/branches/963/src/chrome/browser/chrome_content_browser_client.h?r1=127838&r2=127837&pathrev=127838

Simplest backport of 117417.

Includes about:blank tweak in FilterURL which I will land to 18, 19 shortly.

BUG= 117417 
Review URL: https://chromiumcodereview.appspot.com/9801002
------------------------------------------------------------------------
The reason that rewriting to GURL() was dangerous was that browser_navigator.cc decides that an empty GURL implies a navigation to the home page -- which very often is chrome://newtab/

The other problem is if the compromised renderer passes over a navigation to GURL(). FilterURL leaves it alone, leading to.... a navigation to chrome://newtab/

The solution is to be aware of which urls from the renderer may be empty (e.g. referrer) and which may not (navigations).
Labels: -Restrict-View-SecurityTeam -SecSeverity-Medium -Merge-Approved Restrict-View-SecurityNotify SecSeverity-Low Merge-Merged
Ok we got some but not all into M17. Marking M18.

crrev.com/128077 on M18.
Labels: pwnium
Labels: CVE-2011-3063
Cc: bulach@chromium.org jknotten@chromium.org
Comment 19 by cdn@chromium.org, May 15 2012
Status: Fixed
Marking old security bugs Fixed..
Labels: -Restrict-View-SecurityNotify
Status: Verified
Comment 21 by Deleted ...@, Oct 4 2012
"Ok we got some thing but not all into M17 and Marking M18" http://letdld.blogspot.com same error comes to me .. I also changed the paths
 amirfd45, be sure to download Google Chrome from the true source, namely Google:

https://www.google.com/intl/en/chrome/browser/
Comment 23 by Deleted ...@, Oct 10 2012
Palmer, amirfd45's comment appears to be spam, I have seen the same comment/URL posted on several other bugs. I don't know if this is anything you guys have control over, but the comment should probably be removed.
Project Member Comment 24 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Type-Security -Area-Internals -Feature-Navigation -SecImpacts-Stable -SecImpacts-Beta -SecSeverity-Low -Mstone-18 Security-Severity-Low Security-Impact-Stable Security-Impact-Beta M-18 Cr-Internals Cr-UI-Browser-Navigation Type-Bug-Security
Project Member Comment 25 by bugdroid1@chromium.org, Mar 21 2013
Labels: -Security-Severity-Low Security_Severity-Low
Project Member Comment 26 by bugdroid1@chromium.org, Mar 21 2013
Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member Comment 27 by bugdroid1@chromium.org, Mar 21 2013
Labels: -Security-Impact-Beta Security_Impact-Beta
Project Member Comment 28 by sheriffbot@chromium.org, Jun 14 2016
Labels: -security_impact-beta
Project Member Comment 29 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 30 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
Sign in to add a comment