Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 692378 CSP bypass in domain "chrome://" via.bookmark?
Starred by 2 users Reported by zyzengst...@gmail.com, Feb 15 Back to list
Status: Verified
Owner:
Closed: Mar 23
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: iOS
Pri: 1
Type: Bug-Security



Sign in to add a comment
Steps to reproduce the problem:

1.add a bookmark named "bypass" on chrome iOS version which link is:

javascript:alert(document.location)

2.Then visiting "about:version" and click bookmarks->"bypass".

2. You will find that javascript can execute on "chrome://" of chrome iOS version;But I could not find the same behavior on Chrome desktop version.

What is the expected behavior?

javascript doesn't execute

What went wrong?

javascript executes on domain "chrome://"

Did this work before? N/A 

Chrome version: 56.0.2924.79  Channel: stable
OS Version: iOS 10.2.1
Flash Version:

 
bookmark.PNG
46.7 KB View Download
aboutversion.PNG
169 KB View Download
execute1.PNG
38.4 KB View Download
execute2.PNG
39.5 KB View Download
Components: UI>Browser>Navigation
From a security POV this doesn't seem terribly interesting (the attacker must convince the user to add a dangerous bookmarklet, navigate to a privileged page, and invoke the bookmarklet). 

But the finder is correct in noting that navigation to javascript: URIs is blocked on chrome:// tabs on desktop platforms.
Tactically, this could be fixed by updating loadJavaScriptFromLocationBar to look at the current tab's URL and cancel the script-load operation if the tab is located on a prohibited scheme. That would cover both user-entered JS and bookmarks.
Components: UI>Browser>Bookmarks
Labels: Security_Severity-Low Security_Impact-Stable
Owner: marq@chromium.org
Status: Assigned
marq: could you please help us find an appropriate owner for this? It looks like it's iOS specific.
Cc: sky@chromium.org
cc sky@ for bookmarks
any follow-ups on this issue?
Hello,are experts following up on this issue?
Owner: eugene...@chromium.org
Sorry for the delay in updating this. Assigning to eugenebut@.


@marq OK,thank you very much
Labels: -Pri-2 ReleaseBlock-Stable M-58 Pri-1
Status: Started
Cc: palmer@chromium.org noyau@chromium.org lpromero@chromium.org
Components: -UI>Browser>Navigation
Bookmarks code calls |loadJavaScriptFromLocationBar:|:
https://cs.chromium.org/chromium/src/ios/chrome/browser/ui/bookmarks/bookmark_interaction_controller.mm?q=loadJavaScriptFromLocationBar+package:%5Echromium$&l=305

Chris, what do you think about allowing Bookmarklets on iOS from a security perspective?


Whether or not we support bookmarklets, and if they should be able to mess with WebUI (chrome://*) origins, are product design decisions that are not really in my bailiwick.

It seems to me that bookmarklets (if we support them) shouldn't be able to mess with WebUI. If there is a security issue here, it's that.
Thank you. Desktop does not allow running JavaScript for WebUI pages, so I'm just add the same limitation for iOS.
Cc: kkhorimoto@chromium.org
Labels: Merge-Request-58
Status: Fixed
Project Member Comment 16 by sheriffbot@chromium.org, Mar 23
Labels: -Merge-Request-58 Merge-Review-58 Hotlist-Merge-Review
This bug requires manual review: Less than 29 days to go before AppStore submit on M58
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Hello,can this Reward-topanel?

And I aware that the title of the report maybe inappropriate,could you help me to change this title to be appropriated?such as:"Security:iOS chrome allow JS execution on domain chrome:// WebUI pages"

Oh,sorry,I misspelled a word.It may cause ambiguity. "appropriated" =>"appropriate"
Project Member Comment 19 by sheriffbot@chromium.org, Mar 24
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Cc: awhalley@chromium.org
awhalley@ is this a candidate for "Reward-topanel"?
Cc: srikanthg@chromium.org
Labels: reward-topanel
I'm afraid as a low severity bug it's likely out of scope of the Chrome VRP, but adding the label for consideration.
Status: Verified
Verified on M59.0.3054.0 canary
Device: iPhone7, iPhone6 plus
iOS: 10.3, 10.1.1

Bookmarklets are not executed in Chrome pages.
Bookmarklets continues to work as usual in regular webpages.
Labels: -Hotlist-Merge-Review
Labels: -Merge-Review-58
Labels: -reward-topanel -ReleaseBlock-Stable reward-0
I'm afraid the panel declined to award for this bug. Many thanks for the submission though!
But another low security bug has rewarded to panel(CVE-2016-5193),it also just a small bug in iOS.
Could you think about it again?please.
Labels: -M-58 M-59
Hi zyzengstorm@. Low bugs end up going to the panel only when they are borderline; that one ended up falling on the reward side, this one not. See elawrence@'s comments in #1 about why we think this is very much a low severity issue.  However, since it was in shipping Chrome and we made a fix, it will get a CVE and release noted - how would you like to be credited?
@awhalley OK,thank you for your detail explanation.

Please credit to "Zhiyang Zeng of Tencent security platform department"
Labels: Release-0-M59
Labels: CVE-2017-5085
Project Member Comment 32 by sheriffbot@chromium.org, Jun 30
Labels: -Restrict-View-SecurityNotify allpublic
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
Sign in to add a comment