Summary
Certain network settings in ChromeOS / ChromeBooks persists between reboots when set in guest mode. These issues have been reported to the vendor but will not be fixed since the vendor considers them to be WAI (Working As Intended). These attacks require physical access to the device in order to execute them but future avenues of research looking at network vectors should be undertaken.
Background
ChromeOS is the operating system developed by Google that runs on ChromeBook devices. It is build on top of Linux and around the Chrome browser. The OS has a guest mode which runs Chrome in anonymous mode on top of a temporary guest account. The data within that account is stored in RAM and is erased upon reboot. However, it appears from our research that some settings, especially network related ones, reside elsewhere and do persist between reboots.
Our original interest in this area was prompted by a standing $100,000 USD bounty offered by Google to an exploit “that can compromise a Chromebook or Chromebox with device persistence in guest mode (i.e. guest to guest persistence with interim reboot, delivered via a web page)”. While we have not been able to deliver these attacks via a web page, we did achieve some persistence in network settings in guest mode via physical access. Further research is needed to achieve remote exploitation.
Details
The following network settings were observed in guest mode as persisting between reboots if the change is made by a guest user while the Chromebook is in guest mode:
- Details of WiFi network such as password, authentication, etc.
- Preferred WiFi network
- DNS settings on the currently connected WiFi network
To replicate, do the following:
- Login as a guest into the Chromebook.
- Click on settings, and:
- Try to remove a WiFi network and add a new preferred network;
- Or change settings for an existing network;
- Or change DNS servers for an existing network
- Reboot, re-enter guest mode and observe settings persisting
The following settings only persist when changes are made on the login screen. If a user logs in as a guest user or a Google account, this goes away:
To replicate:
- Start the Chromebook until Login prompt appears. DO NOT login.
- Click on settings, change the proxy settings in the current network.
- Reboot and go back to the login screen, confirm settings for proxy do persist.
- Login to an existing account or as guest, check settings again and observe that proxy settings are now greyed out.
Implications of this are most important in scenarios where a shared Chromebook is used in a public environment such as a library, school, etc. Using these attacks, a malicious user can modify the settings on a public ChromeBook to point to malicious DNS (like DNS Changer virus) or malicious WiFi hotspot, and subsequent users will not realize that their sessions are affected.
We have not been able to achieve remote exploitation, but an existing private Chrome API (chrome.networkingPrivate) would provide access to these settings even in guest mode. This API is not normally available via the Web, so an additional browser exploit would need to be chained to the issues described here to achieve a complete exploit. Another thing to note is that while guest mode normally runs under a RAM disk which is erased after the device is rebooted, the network settings appear to reside elsewhere within the device. That can be used as a further area of possible attacks.
All testing was done in 2016 on the following system, and it is not clear if other ChromeBook hardware is affected:
- Device: Acer C7 Chromebook
- Chrome Versions: 49.0.2623.95, 49.0.2623.111 and 51.0.2704.106 (stable)
- ChromeOS Versions: 7834.60.0, 7834.66.0 and 8172.62.0 (stable parrot)
Vendor Response
The vendor has rejected all of these issues as WAI – working as intended. The vendor has provided the following explanation:
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.
Additional comments from the vendor:
It may be worth noting, as per your original interactions, that the current behavior is by design. Networks may be marked shared or unshared by users, but networks added before sign-in are necessarily global in nature. The default behavior is one meant to minimize unintended side effects — such as one user changing the proxy on another using the same shared network. Beyond that, there is very little difference between connecting to a malicious upstream network and connecting to a non-malicious upstream network. The security of the OS and its communications, using TLS, should remain unperturbed. Guest mode itself does not provide stronger transit privacy guarantees by default as there are few default options for offsetting normal information leakage, such as DNS resolution or IP traffic.
References
Chrome Bugs: 595563, 600194, 600195 and 627299
Chrome Rewards bounty details: see here
Private networking API: see here
Credits
Advisory written by Yakov Shafranovich.
Timeline
2016-03-17: Bug 595563 reported
2016-03-21: Bug 595563 rejected
2016-04-03: Bugs 600194 and 600195 reported
2016-07-12: Bug 627299 reported
2016-08-09: Bugs 600194, 600195, 627299 rejected and opened to the public
2016-10-02: Bug 595563 opened to the public
2017-03-08: Copy of this advisory provided to Google for comment
2017-04-07: Final comments received from Google
2017-04-09: Public disclosure
Nightwatch Cybersecurity 