Attacking the kernel via its command line

Posted Jun 20, 2017 23:39 UTC (Tue) by thestinger (guest, #91827)
Parent article: Attacking the kernel via its command line

Since a proper verified boot implementation (which is more than verifying the boot chain and kernel) can be done *without* taking away control the user at runtime, it's not just dubious to tie them together but actively harmful since it needlessly makes a great security feature less practical by forcing it to be used with another feature...

I really don't see the logic here. The purpose of verified boot is to prevent an attacker from persisting privileged code / trusted data (forcing them to exploit the OS again) or even persisting any code and non-user-configuration/data at all. It also improves physical physical security by doing that as a secondary benefit, particularly if authenticated encryption is used for all user data. It can do that without restricting uncontained root. It can do that alongside that feature too, and there's a bit of synergy there, but it's not particularly strongly connected...

It would have been nice to have a fair and well researched article on this. Unfortunately, a decision was made to push a point of view and leave out entire aspects of the story. Not why I subscribed to lwn. You make it seem like I'm arguing against verified boot being useful when really the context that I'm coming from is that verified boot is important and can and should be properly implemented as done on Android, ChromeOS, CoreOS, etc.

to post comments

Attacking the kernel via its command line

Posted Jun 21, 2017 0:32 UTC (Wed) by walters (subscriber, #7396) [Link] (1 responses)

I recently wrote a blog on this topic: https://blog.verbum.org/2017/06/12/on-dm-verity-and-opera...

Attacking the kernel via its command line

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

FWIW, iOS style third party code signing could be used even with the ability to install third party apps. Android has app code signing but doesn't force everything to have an extra Google signature, but a variant of Android could technically do that, i.e. manual approval for third party apps. It doesn't mean that much on iOS since there are ways to bypass it and the review is very superficial, but it can be done better.

Another issue with code Android is /data/dalvik-cache, since if there's non-preoptimized app code it gets dynamically compiled and used from there. CopperheadOS deals with by preoptimizing all the base system app code / system_server / frameworks and updating it all as part of over-the-air OS updates rather than relying on out-of-band app updates (alongside fully disabling JIT compilation to use full AOT compilation, but that's not related to verified boot). That lets it fully disable execution from /data for the base system without a performance hit (similarly, dynamic code generation / execution in memory and via the file system is disallowed, but that's less tied to verified boot).

There's a lot of trust in the userdata partition for things that are *not* code too, like cached package manager data tracking some properties about installed apps. Introducing verified boot to an existing system is a whole process. For Android, it's useful already, but it's not as powerful as it seems (for now).

Attacking the kernel via its command line

Posted Jun 21, 2017 0:49 UTC (Wed) by corbet (editor, #1) [Link] (19 responses)

I'm not quite sure what point of view you think the article pushes. The thesis here, which I helped the author express, is based on the clear facts that (1) the developers who have actually done the work to implement secure boot on Linux believe that the system software must remain in control at all times, and (2) command-line and module parameters that could be used to defeat that control must be disabled. Given that mindset, this bug must be seen as a security bug. If certain command-line parameters are not safe even for the root user, then certainly a trivial memory-overwrite bug based on command-line parameters cannot be safe.

You don't have to believe that mindset. I don't run locked-down kernels on my systems. But developers whose opinion matters do believe that. I cannot grasp the concept that reporting on this is to "leave out entire aspects of the story". This is a story about a command-line parsing bug...

Attacking the kernel via its command line

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

> is based on the clear facts

Those aren't clear facts, they're a distortion of reality. You're making claims and refusing to justify them.

> the developers who have actually done the work to implement secure boot on Linux believe that the system software must remain in control at all times

So all you have is an argument from authority and the implication that I am not a developer that has worked on verified boot, which is completely false. Distributions like Fedora don't currently have a meaningful secure / verified boot implementation. Unlike others, they haven't done the work to ship the feature.

The developers that have actually done the work to implement meaningful secure boot on Linux (i.e. Google and others) don't use this cargo cult definition of it.

> command-line and module parameters that could be used to defeat that control must be disabled

They still can be with every single one of these bugs fixed.

> Given that mindset, this bug must be seen as a security bug.

The logic doesn't follow. It's only a security bug if a meaningful security feature / security boundary is bypassed. In order for that to matter, there would need to be a more complete verified boot implementation and the kernel line would need to be untrusted. The Linux kernel considers it ultimately trusted. There is no code anywhere to change that. The referenced changes about module parameters, etc. do not change that.

> You don't have to believe that mindset. I don't run locked-down kernels on my systems. But developers whose opinion matters do believe that. I cannot grasp the concept that reporting on this is to "leave out entire aspects of the story". This is a story about a command-line parsing bug...

Okay, just an argument from authority then, and no willingness to actually address the issues pointed out with this reasoning.

Attacking the kernel via its command line

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

You're right but you talk too much; so people stop paying attention.

A picture is worth thousand words. This type of CVE has been pictured many times already. Just re-share one of these pictures and spend your time more productively: https://www.google.com/search?q=security+gate+fail&tb...

Attacking the kernel via its command line

Posted Jun 21, 2017 12:57 UTC (Wed) by corbet (editor, #1) [Link] (3 responses)

No argument from authority. Just a simple statement that a point of view exists and is reasonably widely held, and that, from that point of view, this bug is a security issue.

I understand that you disagree with that point of view. I have not stated my own position with regard to it, so you do not know where I am coming from. Neither of us knows what the author of the article believes. But the fact that "thestinger" reacts like a battered beehive when that point of view is expressed does not make it — or the disagreement over whether this is a security bug — go away.

Attacking the kernel via its command line

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

> No argument from authority

That's *exactly* what you were doing.

> is reasonably widely held

I'm sure where you're getting that data from. It's a very small minority opinion based on off-list talk about it, and there aren't people willing to stand behind it and lay out a justification beyond vague claims.

> Neither of us knows what the author of the article believes

The article presents a case and cherry picks supporting information. A security researcher at Google pointed me to it and referred to it as "highly opinionated".

Attacking the kernel via its command line

Posted Jun 21, 2017 18:48 UTC (Wed) by rahvin (guest, #16953) [Link] (1 responses)

If those opinions are the ones held by the kernel development team responsible for these features and this discussion is limited to linux than it really doesn't matter what anyone else thinks because the people in charge are the ones that are going to make the decision.

You're attacking the article for simply reporting that. You're free to disagree and you're still free to try to convince those developers of the error of their ways. None of this changes the fact that the people with control believe a certain way, the article itself makes no claim of whether that's the right path, only that the people in charge believe it is.

In summary, stop attacking the reporting.

Attacking the kernel via its command line

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

> If those opinions are the ones held by the kernel development team responsible for these features and this discussion is limited to linux than it really doesn't matter what anyone else thinks because the people in charge are the ones that are going to make the decision.

They aren't opinions held by kernel developers.

> You're attacking the article for simply reporting that. You're free to disagree and you're still free to try to convince those developers of the error of their ways. None of this changes the fact that the people with control believe a certain way, the article itself makes no claim of whether that's the right path, only that the people in charge believe it is.

People in charge of kernel development weren't involved.

Attacking the kernel via its command line

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

> I cannot grasp the concept that reporting on this is to "leave out entire aspects of the story". This is a story about a command-line parsing bug...

You might not be able to grasp it, but the article misrepresents my position and reasoning about the issue via omission. It presents it as if I'm arguing against secure / verified boot, and in fact that's the opposite of what's happening. Luckily I can comment here to correct the record about what I said.

I'm arguing for using critical thinking about whether there's a security impact and the response to that only seems to be making an argument from authority / tradition and pushing a definition of 'secure boot' with the scope narrowed to exactly the current state of the implementation in Fedora / RHEL rather than the reality which is that the feature has a whole scale of possible implementations and the one that's present there is not yet a valuable security feature.

I'm happy to listen to an explanation of some setup where this could actually have a security impact. I've yet to see that. No attempt was made to present a scenario where it matters. I don't think there is one. I can certainly imagine a theoretical scenario involving code and a distribution that doesn't currently exist... but it requires truly treating the kernel line as untrusted and verifying at least a portion of userspace. If that was truly implemented, this would be a vulnerability in the system doing that. It still wouldn't be a vulnerability in the mainline Linux kernel itself since that would be a bunch of out-of-tree code...

Attacking the kernel via its command line

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

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.

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