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

Issue 600194 link

Starred by 1 user

Issue metadata

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



Sign in to add a comment

Security: Preferred Network Persists in Guest Mode on ChromeOS

Reported by resea...@nightwatchcybersecurity.com, Apr 3 2016

Issue description

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

 
Cc: bartfab@chromium.org wad@chromium.org pstew@chromium.org
Components: OS>Systems>Network
Labels: OS-Chrome
Owner: jleong@chromium.org
Hello all,

Could you please help with triaging this security ticket.

Very similar to https://bugs.chromium.org/p/chromium/issues/detail?id=595563, but affecting default network.

Many thanks!
Labels: Security_Severity-Low Security_Impact-Stable
Status: Assigned (was: Unconfirmed)
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.
Project Member

Comment 6 by sheriffbot@chromium.org, May 4 2016

Labels: Pri-2
Status: WontFix (was: Assigned)
Closing WAI per https://bugs.chromium.org/p/chromium/issues/detail?id=600195#c13
Labels: -Restrict-View-SecurityTeam
Cc: ya...@nightwatchcybersecurity.com

Sign in to add a comment