Fixed
Status Update
No update yet.
Comments
va...@chromium.org
Thanks for the report.
For #1: Adding the WebUI component folks (calamity@chromium.org, tommycli@chromium.org) to comment on whether that's a bug or working as intended.
For #2: I'm not sure how being able to display a file at a hardcoded path in the user's browser would help an attacker. OP - do you have an attack scenario in mind?
For #3: +rhalavti@ (CCT in Incognito)
For #4: Relying on WebUI folks to comment on this.
For #5: OP - can you please share the crash ID (found on chrome://crashes/) for this crash? Will try to repro this tomorrow.
For #6: Will try to repro this tomorrow.
[Monorail components: Privacy UI>Browser>WebUI]
For #1: Adding the WebUI component folks (calamity@chromium.org, tommycli@chromium.org) to comment on whether that's a bug or working as intended.
For #2: I'm not sure how being able to display a file at a hardcoded path in the user's browser would help an attacker. OP - do you have an attack scenario in mind?
For #3: +rhalavti@ (CCT in Incognito)
For #4: Relying on WebUI folks to comment on this.
For #5: OP - can you please share the crash ID (found on chrome://crashes/) for this crash? Will try to repro this tomorrow.
For #6: Will try to repro this tomorrow.
[Monorail components: Privacy UI>Browser>WebUI]
ju...@gmail.com
Regarding #2: Since the opened file is in the Downloads path, an attacker can easily drop an arbitrary file there. Using a crafted file they can then determine the existence of other files using e.g. img onload and onerror handlers. This is because web origins are not allowed to load images from the file system, but once the file is already opened from a file: or content: URL, there's no such restriction.
Crash ID for #5: f5f296d01dc102f4
Crash ID for #5: f5f296d01dc102f4
[Deleted User] <[Deleted User]>
Thank you for providing more feedback. Adding the requester to the cc list.
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
For more details visit
rh...@chromium.org
Re #4
Thank you for the report.
CCTs opened from incognito mode should be incognito. I will follow it up in a separate thread (https://crbug.com/chromium/1057567 ).
[Monorail components: -Privacy Privacy>Incognito]
Thank you for the report.
CCTs opened from incognito mode should be incognito. I will follow it up in a separate thread (
[Monorail components: -Privacy Privacy>Incognito]
ju...@gmail.com
rhalavati@, can you add me on the CCT issue so I can see where it's going? Ditto for any other new issues created from this.
rh...@chromium.org
Sorry, sure, added.
va...@chromium.org
Thanks.
+twellington@ who is an OWNER at chrome/android/OWNERS for #5.
twellington@:
crash/f5f296d01dc102f4 does not seem to be a security issue since it is an uncaught exception, similar to the one inhttps://crbug.com/chromium/893053 .
If this is something we'd like to fix, would you mind creating a separate bug for this and assigning it to the right owner? Thanks.
+twellington@ who is an OWNER at chrome/android/OWNERS for #5.
twellington@:
crash/f5f296d01dc102f4 does not seem to be a security issue since it is an uncaught exception, similar to the one in
If this is something we'd like to fix, would you mind creating a separate bug for this and assigning it to the right owner? Thanks.
tw...@chromium.org
va...@chromium.org
+Intents folks because most of the issues here are related to firing intents.
Similar tohttps://crbug.com/chromium/1056754#c8 , please file a separate blocking bug if we'd like to investigate or fix the reported problem.
[Monorail components: Mobile>Intents]
Similar to
[Monorail components: Mobile>Intents]
va...@chromium.org
[Thanks twellington@ for filing crbug.com/1057842 ]
mt...@chromium.org
I can handle #1, that's definitely a bug.
mt...@chromium.org
[Empty comment from Monorail migration]
mt...@chromium.org
Just want to note that firefox isn't necessary for #1, you can target a different chrome package and that works too.
mt...@chromium.org
mp...@google.com
Marking as high severity. The abilities to jump out of incognito, view other files in the downloads folder, and spoof google.com are at least high severity.
Re: spoofinggoogle.com . Has this been reproduced? Is it a convincing spoof?
Re: spoofing
mt...@chromium.org
Here's a video of the spoof: https://drive.google.com/a/google.com/file/d/15qfmuupOWkxH8DmdgYA9U8-RcrJGcVTa/view?usp=sharing
It's not the most convincing spoof as you have some weird transition UI and enter fullscreen, but maybe it could be made more convincing. It definitely appears as though the omnibox tells you you're ongoogle.com , when the page you're seeing is not, so that's a big problem.
Also, the omnibox can't be interacted with in this state as Chrome is sitting behind the CCT, and the back button doesn't escape.
It's not the most convincing spoof as you have some weird transition UI and enter fullscreen, but maybe it could be made more convincing. It definitely appears as though the omnibox tells you you're on
Also, the omnibox can't be interacted with in this state as Chrome is sitting behind the CCT, and the back button doesn't escape.
ts...@chromium.org
[Empty comment from Monorail migration]
[Deleted User] <[Deleted User]>
Setting milestone and target because of Security_Impact=Stable and high severity.
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
For more details visit
[Deleted User] <[Deleted User]>
Setting Pri-1 to match security severity High. If this is incorrect, please reset the priority. Sheriffbot won't make this change again.
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
For more details visit
mt...@chromium.org
I think there's just CCT issues remaining? #3 and #6. Over to rhalavati.
rh...@chromium.org
I am waiting to discuss the issue with CCT team next week and proceed based on that. Will update after that.
rh...@chromium.org
Adding peconn@ and dasaic@ for CCT.
pe...@chromium.org
So it looks to me that the bug behind #3 is that Android Intents with Chrome [1] are enabled in Incognito and they should be disabled (or at least require the user to agree). Do people agree with this?
There is another issue of whether we want to allow a webpage to force a link to open in a CCT (by adding ";S.android.support.customtabs.extra.SESSION=;" to the URL), I'm tempted to say no, but I'm unsure.
[1]:https://developer.chrome.com/multidevice/android/intents
There is another issue of whether we want to allow a webpage to force a link to open in a CCT (by adding ";S.android.support.customtabs.extra.SESSION=;" to the URL), I'm tempted to say no, but I'm unsure.
[1]:
rh...@chromium.org
+1
rh...@chromium.org
If there are no objections, I close https://crbug.com/chromium/1057567 and follow up with two new ones as:
- Blocking CCT intents in incognito mode.
- Not allowing a webpage to force a link to open a CCT.
- Blocking CCT intents in incognito mode.
- Not allowing a webpage to force a link to open a CCT.
pe...@chromium.org
To clarify:
- Blocking CCT intents in incognito mode.
Not just CCT intents, all "Android Intents with Chrome" [1]. This is the essential bug.
- Not allowing a webpage to force a link to open a CCT.
I'm happy for there to be a bug for this, although it can probably be a low priority (P2 or so).
[1]:https://developer.chrome.com/multidevice/android/intents
- Blocking CCT intents in incognito mode.
Not just CCT intents, all "Android Intents with Chrome" [1]. This is the essential bug.
- Not allowing a webpage to force a link to open a CCT.
I'm happy for there to be a bug for this, although it can probably be a low priority (P2 or so).
[1]:
rh...@chromium.org
[Empty comment from Monorail migration]
rh...@chromium.org
[Empty comment from Monorail migration]
rh...@chromium.org
[Empty comment from Monorail migration]
[Deleted User] <[Deleted User]>
rhalavati: 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 visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
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
rh...@chromium.org
[Deleted User] <[Deleted User]>
[Empty comment from Monorail migration]
[Deleted User] <[Deleted User]>
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 visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
For more details visit
ro...@google.com
I think all the security vulnerabilities reported here from 1-6 are now fixed. I've landed a fix for #3 and #6 related to CCTs yesterday.
crbug.com/1062548 could potentially be followed up separately.
mt...@chromium.org
I added comments to https://crbug.com/chromium/1062550 , but as far as I know, your change hasn't impacted #6, which should still be reproducible?
ro...@google.com
Yes, sorry that's true. I thought the spoofing was under the incognito context too along with custom tabs.
So, the fix mentioned inhttps://crbug.com/chromium/1056754#c34 is only for #3 and not #6.
So, the fix mentioned in
rh...@chromium.org
[Comment Deleted]
ju...@gmail.com
rhalavati@, did the spoofing in case #6 get somehow addressed already? Or are you saying that the spoof isn't convincing enough to be considered a security issue? Case #6 was never about incognito mode or access to data, so your comment seems a bit confusing.
It's also not about regular CCTs, but the Payment API variant (CUSTOM_TABS_UI_TYPE_PAYMENT_REQUEST), which is specifically what allows the spoofing.
It's also not about regular CCTs, but the Payment API variant (CUSTOM_TABS_UI_TYPE_PAYMENT_REQUEST), which is specifically what allows the spoofing.
ro...@google.com
[Comment Deleted]
rh...@chromium.org
Sorry, Rohit and I had some misunderstanding about the issue, so comments #37 and #39 had some wrong content.
To prevent the wrong flow of reading, I removed them, we shortly add the correct one.
To prevent the wrong flow of reading, I removed them, we shortly add the correct one.
ro...@google.com
[Empty comment from Monorail migration]
ro...@google.com
[Comment Deleted]
ro...@google.com
I've created a new bug report (crbug.com/1083972 ) that is tracking the spoofing issue, with P0. The existing crbug.com/1062550 is more of a product question, so I'm removing that from blocking. Sorry, about the delay, the fix would be done quickly. Thanks
pe...@chromium.org
[Empty comment from Monorail migration]
[Deleted User] <[Deleted User]>
[Empty comment from Monorail migration]
ro...@chromium.org
[Comment Deleted]
ro...@chromium.org
#6 is fixed in the Canary 85.0.4151.2.
I deleted myhttps://crbug.com/chromium/1056754#c46 as I mentioned there all the vulnerabilities are fixed but I was still able to reproduce the Crash #5 (https://crbug.com/chromium/1058032 ) in Chrome version 83.0.4103.60. I've added a video for it [1]. I'm reopening this bug again just to be on the err side.
[1]:https://drive.google.com/file/d/14VZWevz3eThOLnvLe9R5zPRaSH5HRafg/view?usp=sharing
I deleted my
[1]:
ro...@chromium.org
[Empty comment from Monorail migration]
ro...@chromium.org
CL for #5 is now in review here crrev/c/2212169 .
[Deleted User] <[Deleted User]>
[Empty comment from Monorail migration]
[Deleted User] <[Deleted User]>
This is sufficiently serious that it should be merged to stable. But I can't see a Chromium repo commit here, so you will need to investigate what - if anything - needs to be merged to M83. Is there a fix in some other repo which should be merged? Or, perhaps this ticket is a duplicate of some other ticket which has the real fix: please track that down and ensure it is merged appropriately.
This is sufficiently serious that it should be merged to beta. But I can't see a Chromium repo commit here, so you will need to investigate what - if anything - needs to be merged to M83. Is there a fix in some other repo which should be merged? Or, perhaps this ticket is a duplicate of some other ticket which has the real fix: please track that down and ensure it is merged appropriately.
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
This is sufficiently serious that it should be merged to beta. But I can't see a Chromium repo commit here, so you will need to investigate what - if anything - needs to be merged to M83. Is there a fix in some other repo which should be merged? Or, perhaps this ticket is a duplicate of some other ticket which has the real fix: please track that down and ensure it is merged appropriately.
For more details visit
[Deleted User] <[Deleted User]>
This bug requires manual review: Request affecting a post-stable build
Before a merge request will be considered, the following information is required to be added to this bug:
1. Does your merge fit within the Merge Decision Guidelines?
- Chrome:https://chromium.googlesource.com/chromium/src.git/+/master/docs/process/merge_request.md#when-to-request-a-merge
- Chrome OS:https://goto.google.com/cros-release-branch-merge-guidelines
2. Links to the CLs you are requesting to merge.
3. Has the change landed and been verified on master/ToT?
4. Why are these changes required in this milestone after branch?
5. Is this a new feature?
6. If it is a new feature, is it behind a flag using finch?
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), bindusuvarna@(iOS), cindyb@(ChromeOS), srinivassista@(Desktop)
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Before a merge request will be considered, the following information is required to be added to this bug:
1. Does your merge fit within the Merge Decision Guidelines?
- Chrome:
- Chrome OS:
2. Links to the CLs you are requesting to merge.
3. Has the change landed and been verified on master/ToT?
4. Why are these changes required in this milestone after branch?
5. Is this a new feature?
6. If it is a new feature, is it behind a flag using finch?
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), bindusuvarna@(iOS), cindyb@(ChromeOS), srinivassista@(Desktop)
For more details visit
rh...@chromium.org
Assigning to Rohit who actually worked on the last cases.
rh...@chromium.org
[Empty comment from Monorail migration]
ro...@chromium.org
Re: https://crbug.com/chromium/1056754#c55 :
1. Yes, the merge fits within the Merge Decision Guideline as it fixes a high security bugs and it's a safe fix.
2. [1] [2] [3]
3. The change has been landed and verified in Canary 85.0.4151.0.
4. These changes fixes high severity security bugs.
5. No
[1] :https://bugs.chromium.org/p/chromium/issues/detail?id=1062548#c16
[2] :https://bugs.chromium.org/p/chromium/issues/detail?id=1083972#c11
[3] :https://bugs.chromium.org/p/chromium/issues/detail?id=1085476#c2
1. Yes, the merge fits within the Merge Decision Guideline as it fixes a high security bugs and it's a safe fix.
2. [1] [2] [3]
3. The change has been landed and verified in Canary 85.0.4151.0.
4. These changes fixes high severity security bugs.
5. No
[1] :
[2] :
[3] :
na...@google.com
[Empty comment from Monorail migration]
be...@google.com
Adrian, please could you advise on whether we need to take this for next planned respin?
ad...@chromium.org
roagarwal@ benmason@ I'd prefer to review and approve the fixes individually since they may have different risk/reward balances.
I've approvedhttps://crbug.com/chromium/1083972 for merge.
Of the other two, I want to be sure they're really serious security issues before approving merge. Neither is marked as a security bug and so, formally, benmason@ would have to approve their merge.https://crbug.com/chromium/1062548 sounds like it leaks information to other apps on the user's device? - is that a fair summary? In which case I'm disinclined to suggest we merge? https://crbug.com/chromium/1085476 - is that purely a crash bug?
I've approved
Of the other two, I want to be sure they're really serious security issues before approving merge. Neither is marked as a security bug and so, formally, benmason@ would have to approve their merge.
ro...@chromium.org
Hey Adrian, thanks for your comment. I've explained a little more below about the two other issues which may help for merge decisions.
https://crbug.com/chromium/1062548 , allows a website to open a CCT from an incognito session. Therefore, potentially, revealing identity [1] and allowing website to transit from transient in-memory web storage to user's persistent web storage.
https://crbug.com/chromium/1085476 , Yes, it's purely a crash bug. It would allow website to crash the browser and resulting in loss of user session (at-least the incognito sessions). The incognito session may have something very critical to the user.
[1] : A user may have already logged in to the website in regular session. Upon surfing the website incognito, the user can click the link which will open the CCT and since CCT is Chrome it has access to the user cookies too, the user would be logged in automatically and which will reveal their identity.
[1] : A user may have already logged in to the website in regular session. Upon surfing the website incognito, the user can click the link which will open the CCT and since CCT is Chrome it has access to the user cookies too, the user would be logged in automatically and which will reveal their identity.
ad...@chromium.org
Thank you. https://crbug.com/chromium/1062548 could arguably be borderline a security bug, since it allows a remote attacker to defeat the Incognito defenses, but I think we'd normally handle that as a privacy bug. https://crbug.com/chromium/1085476 is definitely not a security bug. As such I think they're correctly filed as type=Bug rather than type=Bug-Security, and benmason@ should decide with you whether either of those needs merging.
I'm removing the merge-review labels from this parent issue since, as far as I understand it, there's no fix to be merged here.
I'm removing the merge-review labels from this parent issue since, as far as I understand it, there's no fix to be merged here.
na...@google.com
Unfortunately the Panel declined to award this report.
na...@google.com
[Empty comment from Monorail migration]
ad...@google.com
Note to self: I'm not going to credit this particular bug in any set of release notes since https://crbug.com/chromium/1083972 was already credited.
[Deleted User] <[Deleted User]>
This bug has been closed for more than 14 weeks. Removing security view restrictions.
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
For more details visit
ha...@google.com
[Empty comment from Monorail migration]
ha...@google.com
[Empty comment from Monorail migration]
ha...@google.com
[Empty comment from Monorail migration]
is...@google.com
This issue was migrated from crbug.com/chromium/1056754?no_tracker_redirect=1
[Auto-CCs applied]
[Multiple monorail components: Mobile>Intents, Privacy>Incognito, UI>Browser>WebUI]
[Monorail blocked-on:crbug.com/chromium/1057567 , crbug.com/chromium/1057842 , crbug.com/chromium/1058032 , crbug.com/chromium/1062548 , crbug.com/chromium/1083972 , crbug.com/chromium/1085476 ]
[Monorail components added to Component Tags custom field.]
[Auto-CCs applied]
[Multiple monorail components: Mobile>Intents, Privacy>Incognito, UI>Browser>WebUI]
[Monorail blocked-on:
[Monorail components added to Component Tags custom field.]
Description
VULNERABILITY DETAILS
Browsable Activities expose various insecure behaviors on Android, accessible via intent: URIs. The security impact of these behaviors ranges from allowing websites to escape incognito mode to navigating to restricted URI schemes and spoofing full-page content on 3rd party websites.
VERSION
Chrome Version: 80.0.3987.117 + stable
Operating System: Android 9
REPRODUCTION CASEhttp://192.168.71.38/chrome.html and http://192.168.71.38/redirect.html , respectively. The former contains a hard-coded reference to the latter.
Attached are two HTML documents: chrome.html and redirect.html, former of which serves as the entry point and contains a list of links demonstrating various behaviors. The files should be hosted as
Below is are some details about each link in chrome.html.
#1: Open arbitrary chrome:// URLs (incognito + user interaction)
------------------------- ---------------------------------------
Install Firefox for Android; try not to get confused, this *is* a Chrome bug, but Firefox has to be installed for this PoC. Load chrome.html in incognito mode in Chrome. Click on the link labeled #1 and you should see a dialog titled "Leave incognito mode?". Select "Stay". The page navigates to chrome://chrome-urls, which is a restricted URL and should not be accessible via web content.
#2: Open downloaded file
Load chrome.html and click on the link. The page navigates to content://com.android.chrome.FileProvider/downloads/payload.html. If you have a file named payload.html in your Android downloads folder, it is loaded. Otherwise ERR_FILE_NOT_FOUND is shown.
Web content should not be able to navigate to local files.
#3: Escape from incognito
-------------------------
Load chrome.html in incognito mode and click on the link. A custom tab opens with example.com in it. This is outside incognito mode.
Incognito mode should always show a confirmation dialog before exiting via a link.
#4: Open arbitrary chrome:// URLs
------------------------- --------
Load chrome.html and click on the link. A custom tab opens to the URL chrome://chrome-urls.
Web content should not be able to load restricted schemes like chrome://.
#5: Crash
Load chrome.html and click on the link. Chrome crashes.
#6: Spoof content
Load chrome.html and click on the link. A popup window opens; click on the button labeled "Continue to google.com". Google.com loads, displaying spoofed content.
CREDIT INFORMATION
Reporter credit: Juho Nurminen of Mattermost