Attacking the kernel via its command line

Posted Jun 22, 2017 17:38 UTC (Thu) by pjones (subscriber, #31722)
In reply to: Attacking the kernel via its command line by thestinger
Parent article: Attacking the kernel via its command line

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

to post comments

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.