Attacking the kernel via its command line

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

> 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?

to post comments

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.