Attacking the kernel via its command line

June 20, 2017

This article was contributed by Nur Hussein

The kernel's command line allows the specification of many operating parameters at boot time. A silly bug in command-line parsing was reported by Ilya Matveychikov on May 22; it can be exploited to force a stack buffer overflow with a controlled payload that can overwrite memory. The bug itself stems from a bounds-checking error that, while simple, has still been in the Linux kernel source since version 2.6.20. The subsequent disclosure post by Matveychikov in the oss-security list spawned a discussion on what constitutes a vulnerability, and what is, instead, merely a bug.

Many kernel command-line parameters allow the specification of an array of integer values, using a syntax like:

    foo=1-10

Within the kernel, the result of such a parameter will be the filling of an array with the values one through ten. Array parameters are parsed with the get_options() function:

    char *get_options(const char *str, int nints, int *ints);

The nints value specifies the maximum number of integer values that should be placed into the ints array. Unfortunately, nobody noticed that get_options() simply ignores nints; if the command line contains a parameter like foo=1-1000000, one-million entries will be written, regardless of whether the destination array has the space to hold them. There are just over 200 get_options() call sites in the 4.12-rc6 kernel; any one of them could be used to overwrite memory via a hostile command line.

The example Matveychikov provided gave a huge range for the netdev parameter, triggering the bug. The overflow can be demonstrated while booting an affected kernel using qemu:

    qemu-system-x86_64 -no-reboot -no-shutdown -kernel \
        /boot/vmlinuz-4.4.0-66-generic -append "netdev=3735928559-3735999999"

The numbers were chosen so that it wrote variants of the hexadecimal number 0xdeadbeef over and over when overflowing into memory (3735928559=0xdeadbeef), demonstrating that a controlled (if restricted) payload is possible. Matveychikov's patch fixing the error was sent to the linux-kernel and stable lists, but it was not merged and seems to have slipped through the cracks.

Indeed, the fate of this patch is instructive in its own right. Even if one is not concerned about any potential security implications of this problem, it still seems like a bug worth fixing. But it disappeared into the linux-kernel noise, and the one maintainer who seems to have read it, Greg Kroah-Hartman, rejected it as a stable-kernel patch submission that did not follow the relevant rules. Nobody has bothered to direct it to a maintainer who will actually apply it, so the problem remains unfixed.

Bug or vulnerability?

This isn't the first bounds-checking error to be exploitable via the kernel command line. Matveychikov points out that this bug is similar to CVE-2017-1000363, an overflow of the parport_nr array. On the oss-security list, Simon McVittie raised the question of whether there is a realistic way for an attacker to exploit the Linux kernel boot command line without already having compromised the system. McVittie asked: "is this a security vulnerability, or just a bug?"

Daniel Micay argued strongly that this bug does not represent a security vulnerability, saying that "it's unreasonable to consider the kernel line untrusted". After all, as Micay elaborated, there is a whole host of command-line knobs that allow users to alter kernel functions. Florian Weimer disagreed, calling it a potential secure boot bypass, "so it matters in some theoretical sense to some downstreams which carry those Secure Boot patches." Kurt Seifried replied that, for the purposes of CVE assignment, this is a vulnerability. Micay took issue with the fact that CVEs are assigned to bugs like this at all, calling it "meaningless Red Hat security theatre". Seifried replied that CVE assignment has nothing to do with Red Hat, and that Micay should take up the issue with the MITRE/CVE Board.

Is this bug a potential secure-boot bypass? Yes, it is. "Secure boot" isn't a monolithic piece of code that ends with UEFI, it also relies on every privileged piece of code down the boot chain to ensure the integrity of the running operating system. The UEFI portion verifies the bootloader and kernel, and will happily hand off execution to any program that's signed, even buggy kernels. That program is supposed to keep control of the system, preventing even a root user from performing actions that could compromise the system; many actions that root can usually perform are often disabled when secure boot is in use.

Thus, secure-boot developers argue, kernel functionality and command-line parameters need to be locked down so that the kernel cannot be modified in ways that will subvert secure boot. For example, this patch from David Howells, which was merged for the 4.12 kernel, provides annotations to mark parameters that affect hardware, which in turn will let the kernel lock some of those parameters down. Buggy command-line processing that allows the overwriting of unrelated memory clearly defeats this sort of lockdown; it can, thus, only be seen as a vulnerability by anybody who is concerned about the use of command-line (or module) parameters to defeat secure boot.

The kernel has certainly been getting more secure over the last few years, with automated tools such as fuzzers and efforts like the Kernel Self Protection Project taking a more proactive approach to security. Bugs still slip in, of course, and sometimes it can take quite some time before they are found and fixed as well. When they are found, though, it is important that those fixes do get merged; letting this one linger helps no one.

Index entries for this article
Kernel	Security
Security	Linux kernel
GuestArticles	Hussein, Nur

to post comments

Attacking the kernel via its command line

Posted Jun 20, 2017 21:59 UTC (Tue) by thestinger (guest, #91827) [Link] (6 responses)

> it also relies on every privileged piece of code down the boot chain to ensure the integrity of the running operating system

Including protecting the integrity of the kernel command-line in the bootloader, and having the kernel verify the integrity of *at least* the base operating system, because the kernel alone doesn't do something useful. It's userspace that makes it do something useful.

> Is this bug a potential secure-boot bypass?

Nope, regardless of people misrepresenting it as such, that doesn't change that it's not. No bugs are required to take control of everything via the kernel line, and that includes kernel code execution.

> That program is supposed to keep control of the system, preventing even a root user from performing actions that could compromise the system; many actions that root can usually perform are often disabled when secure boot is in use.

This doesn't mean anything if even init wasn't verified. There's not really anything further to compromise. If the kernel contains root with SELinux or whatever else, then protecting the kernel from root has value. I'm not sure what the connection is to secure / verified boot though.

> When they are found, though, it is important that those fixes do get merged; letting this one linger helps no one.

Since it doesn't break a meaningful for security boundary for anyone and won't ever be hit in practice, I don't see the point of treating it as a fix worth backporting. It should be fixed, but it's a novelty. Greg has a lot of important patches to backport that aren't yet backported so why waste time on trivialities?

Attacking the kernel via its command line

Posted Jun 20, 2017 22:11 UTC (Tue) by thestinger (guest, #91827) [Link]

And by the way, for the Android (one of the Nexus devices) example where the bootloader had a bug allowing kernel command-line injection, changing the initial root and init is all that's needed to bypass it. Those kernels don't use modules and are perfectly capable of booting from USB, at which point the attacker has full control over the kernel since it's init that's responsible for loading the SELinux policy. There are so many other things that can be messed with like memory layout and the IOMMU though, and there has never been any real attempt to make the kernel line untrusted. There was a more serious effort to start the process of not trusting *module* parameters which makes more sense but is just *barely* a meaningful defense in depth mechanism, not some critical part of enforcing a meaningful security boundary and not something that's sensible to tie to verified boot. It's a false connection being drawn between unrelated features, due to a desperate attempt to give a totally incomplete implementation of verified boot some meaning.

Attacking the kernel via its command line

Posted Jun 22, 2017 17:38 UTC (Thu) by pjones (subscriber, #31722) [Link] (4 responses)

>> Is this bug a potential secure-boot bypass?
>
> Nope, regardless of people misrepresenting it as such, that doesn't
> change that it's not. No bugs are required to take control of everything
> via the kernel line, and that includes kernel code execution.

In the Secure Boot context, this doesn't happen to be the case. The intent is that when SB is enabled, all command line options that would give you a mechanism to break out and effectively use the loaded OS as a bootloader for an untrusted kernel are disabled.

Since this potentially allows arbitrary untrusted code execution from the kernel's privilege level, it's a real vuln in the context of the Secure Boot threat model. From a practical point of view, that means you can use it to build and install a bootkit that persists across OS reinstalls. So yes, it really is a potential Secure Boot bypass, and yes it does actually matter for normal deployment of normal systems.

> This doesn't mean anything if even init wasn't verified. There's
> not really anything further to compromise. If the kernel contains
> root with SELinux or whatever else, then protecting the kernel
> from root has value. I'm not sure what the connection is to
> secure / verified boot though.

What Secure Boot is giving you is the ability to recover from being rooted by an attacker who's actually moderately competent. This bypasses our ability to ensure that, because you can run untrusted kernel code, and therefore you can use a signed bootloader+kernel to launch untrusted kernel code. You can effectively organize that code as a bootloader for what looks like a normal OS, except with a loader that modifies whatever it wants however it wants. With fairly minimal effort, this means a perpetual back door that remains open across kernel upgrades. With a little more effort you can make that continue being true when you boot new install media.

There are several different ways you can accomplish that, some more insidious than others, and there are various bells and whistles that are more effort on top of that, including how hard you want to hide that you're doing it. But those are bells and whistles. Basic exploits of this type have been seen in the wild, and these are what Secure Boot prevents. And talks at security conferences now regularly include methods to do all of this, with the stipulation that Secure Boot must be disabled. This bug gives you a mechanism to build it again with Secure Boot enabled. That's what this has to do with Secure Boot.

What it has to do with "verified boot" or "trusted boot" is nothing at all.

Attacking the kernel via its command line

Posted Jun 22, 2017 18:00 UTC (Thu) by thestinger (guest, #91827) [Link] (3 responses)

> In the Secure Boot context, this doesn't happen to be the case.

Not what secure boot means. You're trying to push a redefinition of a term into one being pushed to market a meaningless non-security feature. Other vendors understand what secure / verified boot actually means:

https://www.qualcomm.com/media/documents/files/secure-boo...

"Secure boot is defined as a boot sequence in which each software image to be executed is authenticated by software that was previously verified"

Note they don't try to change the definition of a feature implemented across many architectures / platforms.

> Since this potentially allows arbitrary untrusted code execution from the kernel's privilege level, it's a real vuln in the context of the Secure Boot threat model.

Not a meaningful threat model and not what secure boot means.

> So yes, it really is a potential Secure Boot bypass, and yes it does actually matter for normal deployment of normal systems.

Nope, not a bypass, and nope, you haven't given one example of how it matters.

> From a practical point of view, that means you can use it to build and install a bootkit that persists across OS reinstalls.

If the persistent kernel line isn't verified... which is a thoroughly broken implementation of secure / verified boot.

> What Secure Boot is giving you is the ability to recover from being rooted by an attacker who's actually moderately competent.

A more complete implementation of secure / verified boot covering the OS makes persistence as root more difficult. Not verifying any of userspace does not.

> You can effectively organize that code as a bootloader for what looks like a normal OS, except with a loader that modifies whatever it wants however it wants. With fairly minimal effort, this means a perpetual back door that remains open across kernel upgrades. With a little more effort you can make that continue being true when you boot new install media.

You can still do exactly this if userspace isn't verified. No value is provided for this threat model that you're describing without verifying any of userspace.

> There are several different ways you can accomplish that, some more insidious than others, and there are various bells and whistles that are more effort on top of that, including how hard you want to hide that you're doing it. But those are bells and whistles. Basic exploits of this type have been seen in the wild, and these are what Secure Boot prevents. And talks at security conferences now regularly include methods to do all of this, with the stipulation that Secure Boot must be disabled. This bug gives you a mechanism to build it again with Secure Boot enabled. That's what this has to do with Secure Boot.

Nope, you're totally wrong. Maybe you should learn some security basics before trying to explain things in a condescending to someone that has a far better grasp on it than you do. If you read what I and other people had written about it, you already would have learned why your view on it isn't correct. Not sure why you're responding without reading first.

> What it has to do with "verified boot" or "trusted boot" is nothing at all.

Secure boot and verified boot are synonyms. You're trying to redefine a long lived industry term to include an orthogonal feature not directly related to it, and to reduce the scope to a nearly worthless implementation. If you want to have a new term for your company's attempt at security features, make a new term for it without a widespread existing definition.

Attacking the kernel via its command line

Posted Jun 22, 2017 19:53 UTC (Thu) by pjones (subscriber, #31722) [Link] (2 responses)

> Not what secure boot means. You're trying to push a redefinition
> of a term into one being pushed to market a meaningless non-security
> feature. Other vendors understand what secure / verified boot
> actually means: <2016 qualcomm presentation url here>

I'm sorry that Qualcomm has tricked you, with this 2016 presentation, into thinking when others are talking about Secure Boot they mean some generic concept. I do not, and neither do others in the quoted article and thread that you seem to so vehemently believe are wrong about (apparently) everything.

The rest of us are having a discussion about the "Secure Boot" term that has been used by basically all the client and server system firmware and bootloader developers across many OSes and companies to refer to one single feature and the ecosystem around it, and that feature has been deployed and supported for *years* now. If you want there to be some generic version that has some more generalized or more hardcore feature set, be my guest, but call it something else if you want people to understand you. Likewise, others likely will not speak in your own personal argot to describe the world they're in.

You can feel free to keep saying otherwise, but it just makes communication with you more difficult. That plus a persistent tone of "no no you're all wrong and biased against me" makes for a quite convincing rhetorical style.

> If you read what I and other people had written about it, you already
> would have learned why your view on it isn't correct.

Not the case. Suffice it to say that as somebody who has spent much time working on these issues, in open source code where everyone can see, I do not agree with your point of view, and find your arguments against what we've done utterly uncompelling in light of a very simple fact: it prevents the actual exploits in the wild.

With that said, and since I see that Florian and Kurt already tried to explain this to you, and you simply refused to listen to anything they said, I think we're done talking. You're clearly not ready to have a civil discussion or try to understand anyone else's point of view, much less the actual technical details.

> Not sure why you're responding without reading first.

Same. Have a nice life.

Attacking the kernel via its command line

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

> I'm sorry that Qualcomm has tricked you, with this 2016 presentation, into thinking when others are talking about Secure Boot they mean some generic concept. I do not, and neither do others in the quoted article and thread that you seem to so vehemently believe are wrong about (apparently) everything.

If you want much older documentation with vendors using the term secure boot... you can have that.

> The rest of us are having a discussion about the "Secure Boot" term that has been used by basically all the client and server system firmware and bootloader developers across many OSes and companies to refer to one single feature and the ecosystem around it, and that feature has been deployed and supported for *years* now. If you want there to be some generic version that has some more generalized or more hardcore feature set, be my guest, but call it something else if you want people to understand you. Likewise, others likely will not speak in your own personal argot to describe the world they're in.

You're the one using a generic term in a niche way. How much market share does desktop Linux have? And by the way, not all desktop and server distributions are interested in an incomplete implementation of secure / verified boot or redefining the term that way.

> Not the case. Suffice it to say that as somebody who has spent much time working on these issues, in open source code where everyone can see, I do not agree with your point of view, and find your arguments against what we've done utterly uncompelling in light of a very simple fact: it prevents the actual exploits in the wild.

It is the case. You're stuck in the bubble of cargo cult security land with apparently no experience with systems using meaningful verified boot which are far more common than the entirety of desktop Linux.

It doesn't prevent actual exploits, and you've been unable to provide any example of that. You made a false claim that this level of incomplete secure / verified boot implementation prevented making a rootkit hiding itself from the rest of the OS.

> With that said, and since I see that Florian and Kurt already tried to explain this to you, and you simply refused to listen to anything they said, I think we're done talking. You're clearly not ready to have a civil discussion or try to understand anyone else's point of view, much less the actual technical details.

You're only interested in pushing marketing drivel and cargo cult security. They didn't try to explain anything. All of you have refused to engage in a technical discussion. You only make arguments from authority and inaccurate claims that you cannot defend.

> Same. Have a nice life.

Have a nice time keeping the information security industry dishonest.

Attacking the kernel via its command line

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

Here's a data sheet talking about Qualcomm Secure Boot from 2007, if it makes you happier. If you'd like, I can give you documentation from multiple vendors from even earlier.

https://www.mobileread.com/forums/attachment.php?attachme...

I'm quite familiar with what desktop Linux distributions are doing, but I don't live in a bubble where those are the only secure / verified boot implementations and they don't get to define generic terms. Elsewhere, there are meaningful implementations that have been shipping for a long time and cover not only the firmware, bootloaders and kernel but also userspace. In the case of iOS, beyond that, but in a weaker way. You would have known that if you had read what I wrote.

Attacking the kernel via its command line

Posted Jun 20, 2017 23:39 UTC (Tue) by thestinger (guest, #91827) [Link] (22 responses)

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.

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

Attacking the kernel via its command line

Posted Jun 21, 2017 10:11 UTC (Wed) by cpitrat (subscriber, #116459) [Link] (2 responses)

It looks like some parts of the kernel would benefit from unit testing ! All the code that doesn't interact with hardware (like implementations of lists, trees, string methods ... that's a lot of code in the end) could easily be unit tested and should have 100% coverage.

Moreover, static analysis is able to detect unused parameter which would have highlighted this bug.

Attacking the kernel via its command line

Posted Jun 21, 2017 14:12 UTC (Wed) by gregkh (subscriber, #8) [Link] (1 responses)

What type of static analysis rule would have caught this issue? If you know of one, please write it so we can ensure it never happens again.

Also, unit tests are great to have we gladly accept patches that add them. Some code, like the resource management logic, does have them, and they are invaluable in testing changes in those areas of the kernel. Please send us more!

Attacking the kernel via its command line

Posted Jun 21, 2017 14:31 UTC (Wed) by cplaplante (subscriber, #107196) [Link]

I am somewhat surprised that Coverity didn't catch this - https://scan.coverity.com/projects/linux.

Attacking the kernel via its command line

Posted Jun 21, 2017 14:10 UTC (Wed) by gregkh (subscriber, #8) [Link] (1 responses)

Note, I want this patch to be merged, and asked the author to submit it properly, they way any other kernel patch needs to be submitted. They never did so from what I could tell, which is why it never got merged :(

Maybe someone has the time to pick it up and do this for them? I know I don't at the moment...

Attacking the kernel via its command line

Posted Jun 21, 2017 15:18 UTC (Wed) by corbet (editor, #1) [Link]

I sent it to Andrew and it's in -mm now.

Attacking the kernel via its command line

Posted Jun 21, 2017 15:53 UTC (Wed) by vegard (subscriber, #52330) [Link]

> Bugs still slip in

Understatement of the year ;-)