Security: Renderer controls whether "Press Esc to show your cursor" warning is shown or not |
||||||||
Issue description
VULNERABILITY DETAILS
The flag that determines whether "silent mouse lock" is used (MouseLockController::IsMouseLockedSilently) is sent over the following IPC from the renderer.
IPC_MESSAGE_ROUTED3(ViewHostMsg_LockMouse,
bool /* user_gesture */,
bool /* last_unlocked_by_target */,
bool /* privileged */)
A compromised renderer could simply set |last_unlocked_by_target| to true and therefore enter mouse lock without showing the status bubble. It looks as though |privileged| can achieve the same thing (this allows Flash to enter mouse lock and promise that it's going to show its own bubble, so the browser doesn't need to). So... I guess this is by design and we can't really fix |privileged| even if we fix |last_unlocked_by_target|.
Maybe this is a WontFix. Filing anyway so we have a bug ID for it.
Since it is (as security severity goes) minor, and requires a renderer escape, it isn't a huge deal.
VERSION
Chrome Version: 60 (r471643); likely goes back years.
Operating System: All desktop
REPRODUCTION CASE
Requires renderer exploit.
,
May 23 2017
Hmm, maybe we will want to fix it. I have two other bugs that seem pretty hard to fix as-is, and maybe will just go away if we stop depending on the renderer: - Issue 724967 - Issue 725370
,
May 23 2017
,
May 23 2017
I'm setting severity to low, but on the fence about whether to remove flags altogether. This doesn't seem like much of an escalation for an attacker who has already compromised a renderer process. It probably becomes more significant when site isolation eventually ships, because at that point being able to manipulate user interaction across different origins becomes a privilege escalation. Maybe it makes sense to leave this locked down because of those other two related bugs, which have clearer security implications.
,
May 23 2017
Pointer lock is not a security or privacy threat. Pointer lock is a UX issue. Data can not be revealed, distributed, etc. This was established in 2011 and occasionally needs to be recirculated. I've brought this up on relevant email thread, will give that time to be addressed, and then clear the security flags from these issues.
,
May 24 2017
,
May 24 2017
,
May 26 2017
Clearing security flags. Unexpected mouse lock can be a user annoyance, and this can be considered a denial of service bug, but since that is the extent of exposure we don't consider it a security vulnerability. https://dev.chromium.org/Home/chromium-security/security-faq#TOC-Are-denial-of-service-issues-considered-security-bugs-
,
Jun 7 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ba34097511607ca63c7377a5db4cbab3e79decf0 commit ba34097511607ca63c7377a5db4cbab3e79decf0 Author: chongz <chongz@chromium.org> Date: Wed Jun 07 14:40:15 2017 [PointerLock] Move "silent mouse lock" logic from renderer to RWHI RWHI should control whether we want to show the "Press Esc to show your cursor" warning instead of renderer. This CL moved existing "silent mouse lock" logic to RWHI without changing the behavior. Future work could be done to optimize the logic, for example, based on bubble timeout. -- Logic for |BrowserPluginGuest| 1. Chrome Apps <webview> send |LockMouse| request to |BrowserPluginGuest| 2. |BrowserPluginGuest| send permission request to host page (via JS) 3. If granted, |BrowserPluginGuest| forward |LockMouse| request to host renderer 4. Host renderer send request to host RWHI Usually we only have step 4. for a normal page. BUG= 725365 Review-Url: https://codereview.chromium.org/2915613004 Cr-Commit-Position: refs/heads/master@{#477639} [modify] https://crrev.com/ba34097511607ca63c7377a5db4cbab3e79decf0/chrome/browser/ui/exclusive_access/flash_fullscreen_interactive_browsertest.cc [modify] https://crrev.com/ba34097511607ca63c7377a5db4cbab3e79decf0/content/browser/browser_plugin/browser_plugin_guest.cc [modify] https://crrev.com/ba34097511607ca63c7377a5db4cbab3e79decf0/content/browser/browser_plugin/browser_plugin_guest.h [modify] https://crrev.com/ba34097511607ca63c7377a5db4cbab3e79decf0/content/browser/renderer_host/render_widget_host_impl.cc [modify] https://crrev.com/ba34097511607ca63c7377a5db4cbab3e79decf0/content/browser/renderer_host/render_widget_host_impl.h [modify] https://crrev.com/ba34097511607ca63c7377a5db4cbab3e79decf0/content/common/view_messages.h [modify] https://crrev.com/ba34097511607ca63c7377a5db4cbab3e79decf0/content/public/test/browser_test_utils.cc [modify] https://crrev.com/ba34097511607ca63c7377a5db4cbab3e79decf0/content/public/test/browser_test_utils.h [modify] https://crrev.com/ba34097511607ca63c7377a5db4cbab3e79decf0/content/renderer/mouse_lock_dispatcher.cc [modify] https://crrev.com/ba34097511607ca63c7377a5db4cbab3e79decf0/content/renderer/mouse_lock_dispatcher.h [modify] https://crrev.com/ba34097511607ca63c7377a5db4cbab3e79decf0/content/renderer/render_widget_fullscreen_pepper.cc [modify] https://crrev.com/ba34097511607ca63c7377a5db4cbab3e79decf0/content/renderer/render_widget_mouse_lock_dispatcher.cc [modify] https://crrev.com/ba34097511607ca63c7377a5db4cbab3e79decf0/content/renderer/render_widget_mouse_lock_dispatcher.h
,
Jun 14 2017
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by mgiuca@chromium.org
, May 23 2017