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

Issue 600195 link

Starred by 1 user

Issue metadata

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

Sign in to add a comment

Security: DNS settings persist in Guest Mode on ChromeOS

Reported by, Apr 3 2016

Issue description

Attacker can change the DNS settings on existing network in guest mode and it will persist for future logins. This is related to bug # 595563 but different than # 600194.

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

1. Login as Guest.
2. Go to the currently used network, and changed DNS settings.
3. Reboot, and login as guest again, the new DNS settings will be used.
5. Reboot as login as a regular user, the new DNS settings will be used.

Once DNS has been changed, the attacker can redirect users to his/her own servers for non-SSLed sites and watch and modify data at will.

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."
Components: OS>Systems>Network
Labels: Security_Severity-Low Security_Impact-Stable OS-Chrome
Status: Assigned (was: Unconfirmed)
This behavior doesn't seem ideal to me, and while the physical access side of it isn't considered in our threat model, it seems like it could potentially be interesting as part of a larger exploit.

Adding some ccs from  issue 595563  to take a look. If this behavior is intentional, feel free to close this out. Just want to make sure someone takes a look.
As with the other bug, you should never trust the network, including its DNS servers. DNSSEC and TLS are the right protections here. Trying to lock down network configuration would just be a band-aid on top.

If this remains assigned to me, I am very inclined to just close it as WAI. Speak up if you disagree.
In an ideal world, DNSSEC and TLS would be deployed everywhere but in today's world most sites do not use either one. Non-technical ChromeBook users, would be affected by this bug, especially if a way is found to deploy it over network. This can result in content being injected in web pages, sites not using TLS being redirected, etc.

On Windows, this is a pervasive problem:

Additionally, monitoring of DNS queries is also considered an attack, as per RFC 7258:
Owner: ----
Unassigning myself. I will leave it to the security team to drive this. From an enterprise POV (my team), there is nothing wrong here.
Project Member

Comment 5 by, May 4 2016

Labels: Pri-2
Status: WontFix (was: Assigned)
Closing based on c#2.
Status: Available (was: WontFix)

Comment 8 by, Jun 10 2016


Comment 9 Deleted

mnissler: thoughts?
Project Member

Comment 12 by, Jul 20 2016

Status: Assigned (was: Available)
Status: WontFix (was: Assigned)
First of all, note that there are quite a few ways for network settings to propagate into sessions. DNS and proxy (per  issue 627299 ) settings are just two of them. You can go further and just join the device to a malicious WiFi network that it'll pick up again after rebooting (this is possible from the login screen, no need to start a guest session). Edit: There are more issues filed for these cases, cf.  issue 600194  and  issue 595563 .

If we were to crack down on propagation of (malicious) network settings into sessions, we'd take quite a UX hit, as we'd have to prompt the user to reconfirm their network settings whenever the device is connected to a network that user hasn't yet approved (and it's quite unlikely for this to be effective). The alternative of only allowing the device owner to configure networks doesn't fly either as it has the potential to lock out legitimate users.

Regarding programmatic injection of network settings, there is (1) device policy, which is already properly locked down (i.e. only open to enterprise admins, and settings aren't Chrome-writable) and (2) chrome.networkPrivate, which is used by the settings screens and (3) direct DBus communication to shill. #2 and #3 require a Chrome browser exploit.

Even if malicious network config gets picked up by a session, it's not entirely game over - TLS will flag maliciously redirected requests (assuming the attacker doesn't have forged certs). There's a chance of information leakage via insecure connections and/or observing the network though.

Given the above, the currently implemented trade-off is reasonable, so I'll close this (and related bugs) as WAI. I've also updated the chromiumos sites page mentioned above - networks were never part of the protected device settings anyways, so the cited half-sentence was inaccurate from the start AFAICT.
Labels: -Restrict-View-SecurityTeam

Sign in to add a comment