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:
https://www.trendmicro.com/vinfo/us/threat-encyclopedia/web-attack/125/how-dns-changer-trojans-direct-users-to-threats
http://www.dcwg.org/

Additionally, monitoring of DNS queries is also considered an attack, as per RFC 7258:
https://tools.ietf.org/html/rfc7258

Unassigning myself. I will leave it to the security team to drive this. From an enterprise POV (my team), there is nothing wrong here.

Closing based on c#2.

Reopening.

Related bug:
https://bugs.chromium.org/p/chromium/issues/detail?id=627299

mnissler: thoughts?

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.