Attacking the kernel via its command line

Posted Jun 21, 2017 7:04 UTC (Wed) by marcH (subscriber, #57642)
In reply to: Attacking the kernel via its command line by thestinger
Parent article: Attacking the kernel via its command line

> This would be ChromeOS if it didn't have extensions, apps and Android app support.

ChromeOS is perfectly usable (and being used) without any of these.

Granted: leaving security in the hands of the end user is foolish</troll> but hey, even with this caveat it's still very "real".

to post comments

Attacking the kernel via its command line

Posted Jun 21, 2017 7:07 UTC (Wed) by thestinger (guest, #91827) [Link] (7 responses)

> ChromeOS is perfectly usable (and being used) without any of these.

It's certainly usable without them, but since it supports them the verified boot implementation is weakened to support them whether or not you use those features. The user having no extensions is something that depends on persistent state.

Attacking the kernel via its command line

Posted Jun 21, 2017 7:27 UTC (Wed) by marcH (subscriber, #57642) [Link] (6 responses)

Can you elaborate, an example of an attack relying on this "weakening" maybe?

Attacking the kernel via its command line

Posted Jun 21, 2017 7:36 UTC (Wed) by thestinger (guest, #91827) [Link] (5 responses)

The context is the strength of verified boot, which verifies the OS but not persistent state. If an attacker gets root (RCE + LPE) they can modify any persistent state so anything that can be in persistent state (apps, extensions, settings, user media files) is something they can use to persist past a reboot despite verified boot. Since ChromeOS permits unprivileged non OS code, an attacker can persist via that code without a verified boot bypass and then reuse another LPE exploit. If it didn't support extensions and especially the new less well contained Android app support (outside the strong browser renderer sandbox), an attacker couldn't permit code without exploiting verified boot. Alternatively, they could get persistence with something like a persistent media file exploiting something like a thumbnail generation service.

Attacking the kernel via its command line

Posted Jun 21, 2017 7:37 UTC (Wed) by thestinger (guest, #91827) [Link]

> couldn't permit code

s/permit/persist/

Attacking the kernel via its command line

Posted Jun 21, 2017 7:56 UTC (Wed) by marcH (subscriber, #57642) [Link] (3 responses)

Pretty sure the persistent partition has existed since the beginning to support user files; it didn't "appear and weaken" the system later.

So, sorry but I still can't see any security difference between the original ChromeOS design versus the current design used by a paranoid user who says away from apps etc. I'm not saying a persistent partition is good, I'm merely saying the design wasn't weakened by apps unless you use some.

Attacking the kernel via its command line

Posted Jun 21, 2017 8:02 UTC (Wed) by thestinger (guest, #91827) [Link]

> paranoid user who says away from apps

The topic is verified boot, not users exposing themselves to additional attack surface by using new features. In terms of impact on verified boot security, it doesn't matter whether you use the features. It only matters that the verified OS code supports those features via the persistent state. It doesn't support persistent privileged code (i.e. the persistent state is not trusted much) which is why it has a good / useful verified boot implementation, but not a fantastic one.

Look back at the context:

> 9) firmware / bootloaders / kernel / base OS / privileged code / data trusted by privileged code / all code / all data trusted by code
> This would be ChromeOS if it didn't have extensions, apps and Android app support.

I only stated that it would be a stronger implementation of verified boot without any persistent code.

Persistent data without supporting persistent code would mean an attacker's persistence mechanism doesn't start off with (sandboxed) code execution.

Attacking the kernel via its command line

Posted Jun 22, 2017 13:22 UTC (Thu) by walters (subscriber, #7396) [Link] (1 responses)

I think what @thestinger is getting at here is that if someone achieved e.g. RCE on ChromeOS, they'd be able to install (malicious) extensions or apps, and those would persist. These persistent extensions/apps can have greater privileges than was possible on the original ChromeOS that simply didn't have that functionality.

Attacking the kernel via its command line

Posted Jun 22, 2017 13:36 UTC (Thu) by thestinger (guest, #91827) [Link]

Since the attacker gained root with RCE + LPE, they control all of the persistent OS state. On Android, they can persist via /data/dalvik-cache which provides code execution as system_server and base system apps with special privileges granted via being located in /system/priv-app or their signatures. CopperheadOS disables /data/dalvik-cache usage for code and instead uses full pre-compilation for all of the base system. An attacker can still persist via a regular unprivileged app and they can grant their app all of the privileges available to third party apps including those that require explicit user consent. They aren't limited to regular permissions, since they can also make it an accessibility service and a device manager. There's also a lot of other highly trusted OS state. The intention in CopperheadOS is to chip away at all of that.

The unfortunate reality of verified boot is that you can't improve it via settings. There cannot simply be a setting to disable attack surface or to implement more user control because an attacker that has gained root access can change any setting, install any app, grant any dynamic privilege that's possible to set for third party code, etc.

Now that ChromeOS is gaining Android app support (currently in the Beta channel), that all applies to ChromeOS within the Android userspace container. An attacker would need a kernel exploit to get at the non-Android OS, but they'll have control as system_server since it's just standard Android with /data/dalvik-cache and that gives them a huge amount of attack surface since it's near root (in this case, user namespace root, but that still exposes most kernel attack surface).