Status Update
Comments
fa...@gmail.com <fa...@gmail.com> #2
Similar issue, see:
ct...@chromium.org <ct...@chromium.org> #3
Thanks for the report!
After turning on full keyboard access in the macOS Accessibility settings I was able to successfully reproduce on my large monitor -- however, the popup window and permission prompt are visible, just way off to the side and maybe easy to miss (see attached screenshot). When I try on my smaller laptop display, this no longer reproduces for me. Full keyboard access on macOS shows outlines for the element that is under focus, so I can see that the keyboard input is still controlling focus on the permission prompt which does seem to indicate that this is maybe possible, but maybe the occlusion checking is working and disabling submitting the "allow" decision while occluded?
Are there setup steps I'm missing here? Or is this maybe platform specific to Windows? I can quick try on Linux as well.
fa...@gmail.com <fa...@gmail.com> #4
Increasing the left and top values can completely hide it. I used the minimum left and top values to hide it on my PC. You can try changing them, or maybe use left=1500 and top=1500.
fa...@gmail.com <fa...@gmail.com> #5
If possible, could you try this on a Windows machine. My PoC is based on (made for) Windows 11 OS.
ct...@chromium.org <ct...@chromium.org> #6
It appears that focus goes back to the PiP window and/or the focus in the permission popup resets to the first element (so not Allow), breaking the PoC on macOS. I'll spin back up my Windows VM to test there as I do expect this may be platform dependent.
ct...@chromium.org <ct...@chromium.org>
ct...@chromium.org <ct...@chromium.org> #7
Ah hmm I can't test in my VM because it doesn't have a camera device so the permission request just fails.
Routing this to PiP and permissions folks from
Setting some security labels:
- Severity-Medium (S2) hidden interaction with permissions prompt (spoofing) but with significant user interaction required
- OS: Seems likely to be triggerable with some modifications on all Desktop platforms
- FoundIn-128
st...@chromium.org <st...@chromium.org> #8
ct...@chromium.org <ct...@chromium.org> #9
Ah excellent, with that flag I can confirm I can repro on Windows Canary M130, with chrome://flags#one-time-permission enabled and passing --use-fake-device-for-media-stream on the command line.
pe...@google.com <pe...@google.com> #10
Setting milestone because of s2 severity.
pe...@google.com <pe...@google.com> #11
Setting Priority to P1 to match Severity s2. If this is incorrect, please reset the priority. The automation bot account won't make this change again.
el...@google.com <el...@google.com>
st...@chromium.org <st...@chromium.org> #12
Or is there an alternative solution you think we should consider?
el...@google.com <el...@google.com> #13
[1]
st...@chromium.org <st...@chromium.org>
ap...@google.com <ap...@google.com> #14
Branch: main
commit 4fcc965f7b6a9aa9965bc84e0a180eda77a20467
Author: Tommy Steimel <steimel@chromium.org>
Date: Thu Sep 12 13:25:16 2024
pip occlusion: Prevent immediate interaction after unocclusion
We currently prevent input into a permission prompt while it's occluded
by a picture-in-picture window. However, some spoofs can still happen
immediately after a prompt because unoccluded.
This CL prevents permission dialogs from being interacted with
immediately after they're no longer occluded by a picture-in-picture
window.
Bug: 364508693
Change-Id: Ib52d1af8bc5216a50a089e319dea31f0bab108c1
Reviewed-on:
Commit-Queue: Tommy Steimel <steimel@chromium.org>
Reviewed-by: Elias Klim <elklm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1354501}
M chrome/browser/ui/views/permissions/permission_prompt_base_view.cc
st...@chromium.org <st...@chromium.org>
sp...@google.com <sp...@google.com> #15
Hello,
Congratulations! The Chrome Vulnerability Rewards Program (VRP) Panel has decided to award you $1000.00 for this report.
Rationale for this decision:
report of lower impact web platform privilege escalation / security UI bug
Important: If you aren't already registered with Google as a supplier, p2p-vrp@google.com will reach out to you. If you have registered in the past, no need to repeat the process – you can sit back and relax, and we will process the payment soon.
If you have any payment related requests, please direct them to p2p-vrp@google.com. Please remember to include the subject of this email and the email address that the report was sent from.
Thank you for your efforts and helping us make Chrome more secure for all users!
Cheers,
Chrome VRP Panel Bot
P.S. One other thing we'd like to mention:
* Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
Please contact security-vrp@chromium.org with any questions.
am...@chromium.org <am...@chromium.org> #16
Congratulations Shaheen! While the permissions dialog is pretty well hidden from the user here, there are very high user interaction preconditions required here, as such we consider this a lower impact issue. We appreciate the efforts and reporting this issue to us!
pe...@google.com <pe...@google.com> #17
This bug has been closed for more than 14 weeks. Removing issue access restrictions.
Description
SUMMARY
The Permission prompt can be obscured by a Picture-in-Picture (PiP) window for video or documents, potentially allowing a page to obtain permissions without user awareness.
Current address bar permission prompts do check for PiP window occlusion. This issue is very similar to issue 342194497 , with the key difference being that final approval of the permission dialogue requires pressing Enter twice. Since the prompt behind the PiP window is protected, the user is led to press Enter twice—first to close the PiP window and then to approve the permission. Therefore, Chrome should implement a delay here to mitigate this issue.
To minimize user interaction, a compromised renderer can open the PiP window, as seen in issue 338398040 .
VULNERABILITY DETAILS
A page can display a Video or Document PiP window over a normal window with a permission prompt, obscuring the prompt and unknowingly allowing it when the user interacts with the webpage.
An attacker can instruct the user to press keys while the permission prompt is obscured. For example, pressing Tab three times followed by Enter twice can result in the user granting permissions without their awareness.
VERSION
REPRODUCTION CASE
Note: The Proof of Concept (PoC) uses Document PiP, but this also works with Video PiP.
Prerequisites: None required.
poc.html
andpermission.html
files.poc.html
directly from the same folder.Observed: The attacker can obtain permissions without the user’s awareness.
Expected: The attacker should not be able to obtain permissions without the user’s awareness.
CREDIT INFORMATION
Reporter credit: Shaheen Fazim