New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 1 user

Issue metadata

Status: WontFix
User never visited
Closed: Aug 2016
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug-Security

Sign in to add a comment

Issue 600194: Security: Preferred Network Persists in Guest Mode on ChromeOS

Reported by, Apr 3 2016

Issue description

Attacker can change the preferred network in guest mode and it will persist for future logins. This is related to bug # 595563

Chrome Version: 49.0.2623.111
Operating System: 7834.66.0 stable parrot - ChromeOS

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:

"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."

Comment 1 by, Apr 4 2016

Components: OS>Systems>Network
Labels: OS-Chrome
Hello all,

Could you please help with triaging this security ticket.

Very similar to, but affecting default network.

Many thanks!

Comment 2 by, Apr 4 2016

Labels: Security_Severity-Low Security_Impact-Stable

Comment 3 by, Apr 4 2016

Status: Assigned (was: Unconfirmed)

Comment 4 by, 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.
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.

Comment 6 by, May 4 2016

Project Member
Labels: Pri-2

Comment 7 by, Aug 9 2016

Status: WontFix (was: Assigned)
Closing WAI per

Comment 8 by, Aug 9 2016

Labels: -Restrict-View-SecurityTeam

Comment 9 by, Mar 9 2017


Sign in to add a comment