Attacking the kernel via its command line

Posted Jun 21, 2017 2:10 UTC (Wed) by thestinger (guest, #91827)
In reply to: Attacking the kernel via its command line by corbet
Parent article: Attacking the kernel via its command line

There's a whole spectrum of secure / verified boot:

1) nothing
2) firmware
3) firmware / bootloaders
4) firmware / bootloaders / kernel

This is where the distributions being talked about are. I don't think it provides any substantial security properties. Maybe I'm missing something, and if so I'd like to know what...

5) firmware / bootloaders / kernel / base OS

This is where it starts becoming useful. At the very least, it's possible to get guarantees like an Android factory reset being guaranteed to wipe away any malware unless verified boot is exploited. That's the primary guaranteed offered by non-hardened Android: all of the fanciness of the hardware root of trust, the late stage bootloader verifying the kernel and the kernel verifying the entire base OS pretty much just adds up to hardened factory resets when done via booting directly into recovery rather than doing it from the OS.

6) firmware / bootloaders / kernel / base OS / privileged code

Now an attacker needs to exploit the OS after a reboot to get back privileged code execution. Can consider this to be granular, since they may be able to persist code with some privileges but not others. At the very least it needs to protect enough code to provide some kind of useful security model despite an attacker controlling all of the unverified state.

7) firmware / bootloaders / kernel / base OS / privileged code / data trusted by privileged code

This is iOS, ChromeOS and where Android strives to be, but Android places a lot more trust in persistent state than iOS and ChromeOS. So you could consider Android to be here, but an attacker has so much control via /data/dalvik-cache, etc. They control system_server and privileged apps. That's one of the things CopperheadOS currently fixes to make verified boot stronger, but there's a lot more that can be done.

8) firmware / bootloaders / kernel / base OS / privileged code / data trusted by privileged code / all code

iOS is close to being here, but they only do cursory review of the third party code they're signing. It's not same thing as a system where only code from a trusted party is signed.

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.

10) everything (no persistent state)

The ideal is of course not having any persistent state. Everything verified, no way for an attacker to maintain a presence without exploiting the verified boot implementation.

to post comments

Attacking the kernel via its command line

Posted Jun 21, 2017 2:20 UTC (Wed) by thestinger (guest, #91827) [Link] (1 responses)

> 2) firmware

This can provide value if there's a Trusted Execution Environment with either dedicated storage and/or hardware-bound keys accessible to it but not the OS. It protects data stored there even if the attacker gets control over the OS. It's just that jumping to 3 or 4 but not any further doesn't really add anything compelling...

> 4) firmware / bootloaders / kernel

And "kernel" includes verifying the kernel line... unless you make it fully untrusted. It doesn't include protecting the kernel from the OS. That's not really part of verified boot.

Attacking the kernel via its command line

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

> It doesn't include protecting the kernel from the OS. That's not really part of verified boot.

At least in the lines below where init and SELinux policies, etc. are verified and cannot be disabled, so protection of the kernel happens via userspace, which must be verified regardless to guarantee anything useful...

Anyway, it all seems pretty clear to me. I don't see what's missed. Not going to bother trying to explain it further though. I already stated on this on the list and it was just ignored here, so what's the point?

Attacking the kernel via its command line

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

> 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".

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).