Re: [cros-discuss] Chromebook Verified Boot and Persistent Compromises

[Richard Barnette]

> On Apr 1, 2018, at 5:16 PM, CuriousCustomer <samburg...@gmail.com> wrote:
>
> Hi there,
> I'm considering getting a Chromebook for its world-class safety and security mechanisms.
>
> I have some remaining concerns and curiosities, though. It is often said that a persistent compromise of the Chromebook is impossible, aside from malicious browser plugins and extensions.
>
> Sandboxing and verified boot seem to be the keys to the enhanced security of CrOs. In light of the demonstrated persistent RCE compromises achieved twice by bounty-winning researcher Gzob Qq (please see https://nakedsecurity.sophos.com/2017/11/22/chromebook-exploit-earns-researcher-second-100k-bounty/ and https://bugs.chromium.org/p/chromium/issues/detail?id=648971), I'd like to ask if anyone can explain, in layman's terms, how this researcher was able to achieve persistence.
>
> 1) I understand sandboxing vulnerabilities and sandbox escape are a rare fact of life and new exploits will be discovered from time to time. But why was verified boot unable to catch the persistent modification to the OS?
>
Verified boot protects two portions of system data through a
digital signature:
* The kernel.
* The root file system.

However, the system also contains writable data, which isn't
(and can't be) protected by the verification process. The
specific exploit cited took advantage of some of that
unverified data.


> 2) Did the exploit it write something into the OS partition or the user partition that is loaded when the OS boots up in order to achieve persistence?
>
The exploit compromised stateful partition data stored under
/var. By necessity, this data:
* Is writable.
* Is persistent across boots.
* Can't be protected by verification.

The particular data that was compromised is read during boot,
so the net effect was that at boot time, the compromised data
would trick the boot process into re-enabling the malicious
code.


> 3) How could one mitigate and regain control after a theoretical compromise? I understand the chances of this happening to anyone are low (and this specific route in the linked article is impossible since version 62). I am curious about "if/how it is possible to disinfect?" in this unlikely event. Would a powerwash do? Why or why not?
>
Powerwash wipes out and reformats the stateful partition. That
means that, for this exploit, powerwash would remove all of the
compromised files, thus removing the malicious code. More broadly,
one of the uses of powerwash is that can clean up this particular
class of persistent exploit.


> Thank you so much.
>
> --
> --
> Chromium OS discuss mailing list: chromium-...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en
>

[Mattias Nissler]

On Mon, Apr 2, 2018 at 7:13 PM Richard Barnette <jrbar...@chromium.org> wrote:

> On Apr 1, 2018, at 5:16 PM, CuriousCustomer <samburg...@gmail.com> wrote:
>
> Hi there,
> I'm considering getting a Chromebook for its world-class safety and security mechanisms.
>
> I have some remaining concerns and curiosities, though. It is often said that a persistent compromise of the Chromebook is impossible, aside from malicious browser plugins and extensions.

Ah, whoever says that exploitation is impossible shouldn't be trusted :-D

There'll always be bugs (at least unless something changes fundamentally in the software industry), so we can only strive to raise the bar for successful exploitation. Which is exactly what we do - see below for more color on that.

 

>
> Sandboxing and verified boot seem to be the keys to the enhanced security of CrOs. In light of the demonstrated persistent RCE compromises achieved twice by bounty-winning researcher Gzob Qq (please see https://nakedsecurity.sophos.com/2017/11/22/chromebook-exploit-earns-researcher-second-100k-bounty/ and https://bugs.chromium.org/p/chromium/issues/detail?id=648971), I'd like to ask if anyone can explain, in layman's terms, how this researcher was able to achieve persistence.
>
> 1)  I understand sandboxing vulnerabilities and sandbox escape are a rare fact of life and new exploits will be discovered from time to time. But why was verified boot unable to catch the persistent modification to the OS?
>
Verified boot protects two portions of system data through a
digital signature:
  * The kernel.
  * The root file system.

However, the system also contains writable data, which isn't
(and can't be) protected by the verification process.  The
specific exploit cited took advantage of some of that
unverified data.

To elaborate a bit on the nature of this data: There are system-wide log files, network configuration data, state kept by system daemons (power management configuration, network configuration, etc.), a few cache files, to name a few specific examples. Generally speaking, we keep most data in the encrypted user data directories, which helps increase our chances that we'll be able to boot to the login screen without getting compromised.

 

> 2) Did the exploit it write something into the OS partition or the user partition that is loaded when the OS boots up in order to achieve persistence?
>
The exploit compromised stateful partition data stored under
/var.  By necessity, this data:
  * Is writable.
  * Is persistent across boots.
  * Can't be protected by verification.

The particular data that was compromised is read during boot,
so the net effect was that at boot time, the compromised data
would trick the boot process into re-enabling the malicious
code.

To expand a bit - in a nutshell, the situation is this:

• The attacker can't modify any binary code we're executing during boot (startup scripts, system services, UI, etc.), period.
  
• Thus, the attacker needs to trick the legit code to go off rails and perform operations that will re-exploit the device.
• To achieve this, before rebooting the attacker stages malicious data in the stateful file system that will trigger unexpected consequences when the file system gets consumed by legit code.
• In the cited examples, the attack relied heavily on symlinks (which persist across reboot in the stateful file system) to make system services send legit file writes to unintended locations. Generally speaking, an attacker who manages to get privileged code write data controlled by the attacker to a file of their choice has almost won - it's still a bit of puzzle work to find something that consumes the malicious file that gets generated and turns it into code execution, but this is generally possible.
• In response to the cited research, we have locked down symlinks - we now block symlink traversal in the kernel for most of /var, so it'll be interesting to see what other vectors we'll see in vulnerability reports.

> 3) How could one mitigate and regain control after a theoretical compromise? I understand the chances of this happening to anyone are low (and this specific route in the linked article is impossible since version 62). I am curious about "if/how it is possible to disinfect?" in this unlikely event. Would a powerwash do? Why or why not?
>
Powerwash wipes out and reformats the stateful partition.  That
means that, for this exploit, powerwash would remove all of the
compromised files, thus removing the malicious code.  More broadly,
one of the uses of powerwash is that can clean up this particular
class of persistent exploit.

Strictly speaking, powerwash isn't the ideal tool for getting the state back into known good state. If the system is compromised, it could fake the powerwash experience to trick the user into thinking the device got wiped when in fact that didn't happen. You want a way of wiping the device that a compromised system can't prevent. The "recovery" process was designed to cover this need. You can tell firmware (by pressing Esc-Refresh-Power) that you want to re-install the OS from storage media. It will then boot the installer from a USB drive or SD card you supply to wipe the system and reinstall the OS. The idea is that at the point the firmware branches into the recovery process, it is highly unlikely (as unlikely as we can hope for) for the system to be already compromised. This help article details the process: https://support.google.com/chromebook/answer/1080595?hl=en

 

> Thank you so much.
>
> --
> --
> Chromium OS discuss mailing list: chromium-...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en
>

--
--
Chromium OS discuss mailing list: chromium-...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dis...@chromium.org.