Issue metadata
Sign in to add a comment
|
Security: Preferred Network Persists in Guest Mode on ChromeOS
Reported by
resea...@nightwatchcybersecurity.com,
Apr 3 2016
|
||||||||||||||||||||||
Issue descriptionVULNERABILITY DETAILS Attacker can change the preferred network in guest mode and it will persist for future logins. This is related to bug # 595563 VERSION Chrome Version: 49.0.2623.111 Operating System: 7834.66.0 stable parrot - ChromeOS REPRODUCTION CASE 1. Login as Guest. 2. Remove preferred Wifi network, and add a new one. 3. Make the new network preferred. 4. Reboot, and login as guest again, the new network will be used. 5. Reboot as login as a regular user, the new network will be used. Attack scenario would be a public place like a library or Starbucks with a shared ChromeBook available for users. The attacker would setup their own network with a sniffer and an MITM proxy, and then will switch the public ChromeBook to use his/her network. All subsequent users will default to the new network. An additional level of exploitation would occur if a webpage or download file can get access to the "chrome.networkPrivate" APIs, and can modify these settings without physical user access. This may be someone mitigated by not allowing guest users to change network settings, but should still be fixed. Original ChromeOS design document for security specifically addresses this case: https://www.chromium.org/chromium-os/chromiumos-design-docs/user-accounts-and-management#TOC-Incognito-mode "Only the Owner should be able to change system settings. We don't want random users able to add to the whitelist, set the device to promiscuous mode, or reset the default network."
,
Apr 4 2016
,
Apr 4 2016
,
Apr 5 2016
I do not see a security issue here. By definition, all networks should be considered untrusted. Chrome OS also protects against the MitM proxy issue: By default, proxies set on a shared network are ignored. Users have to explicitly opt in to use such proxies. Thus, all the attacker can do is connect the device to a WiFi network of their choice - since we should not be trusting networks to begin with, I see nothing dangerous in that.
,
Apr 5 2016
As indicated in the other bug, in the real world, this would still be an issue since users would be affected because TLS and DNSSEC is not deployed widely, albeit this particular one is mitigated by the need to have physical access.
,
May 4 2016
,
Aug 9 2016
Closing WAI per https://bugs.chromium.org/p/chromium/issues/detail?id=600195#c13
,
Aug 9 2016
,
Mar 9 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by penny...@chromium.org
, Apr 4 2016Components: OS>Systems>Network
Labels: OS-Chrome
Owner: jleong@chromium.org