Practical security for 2014 [LWN.net]

Practical security for 2014

Posted Jan 11, 2014 22:39 UTC (Sat) by paulj (subscriber, #341)
In reply to: Practical security for 2014 by raven667
Parent article: Practical security for 2014

Then what is the practical system security goal for SecureBoot? (Other than the tautologous-ish "Verify the code being loaded is what is meant to be"). You agree that this shifts the goal-posts to next code being run. You agree that code can never be made secure (and, again, it isn't even safe to think that code can converge /toward/ being secure, as our systems get more complex and more featureful), hence may I presume you would agree the resulting system is still persistently subvertable?

In which case, what exactly was the point of the SecureBoot?

I disagree the goal-posts have been shifted to a reduced attack surface. The attack surface is quite large compared to the kernel, and we've made *no progress* on improving the overall security of the latter. Again, you agree that software can not be made secure¹, yet you're pinning your hopes on making the SecureBooted software secure!

Where is your chance of not being fucked? You can only be basing this on there (maybe) not existing tools today to persistently subvert the system through data-reading attacks. If that is true, that is only because the tool-makers havn't needed to do this yet. There is no good reason to think this step will trouble the rootkit tool-makers, once they need to take that step.

There's a massive amount of very wishful thinking going on in those who think SecureBoot is going to buy anything beyond the most short-term of an edge. Maybe a somewhat similar kind of wishful thinking to what I had when I first installed an early rootkit-checker (that was maybe useful for a short time, a very short time, then the rootkit makers adapted). ;)

1. I disagree a little with this. At least, I think the rampant insecurity of system software today could be massively improved with better tools and programming languages. Never perfect, but certainly a lot better than today's situation of system software being written in C/C++ (or running on interpreters written in C/C++), on hardware that can do very little checking of things.

to post comments

Practical security for 2014

Posted Jan 12, 2014 0:10 UTC (Sun) by raven667 (subscriber, #5198) [Link] (4 responses)

> I disagree the goal-posts have been shifted to a reduced attack surface. The attack surface is quite large compared to the kernel, and we've made *no progress* on improving the overall security of the latter. Again, you agree that software can not be made secure¹, yet you're pinning your hopes on making the SecureBooted software secure!

I believe that computers cannot be made 100% secure, but things can be made more or less secure and that SecureBoot makes forward progress toward more secure. There are fewer attack paths and less trusted code as each step gets the chance to verify the next, it isn't all blindly trusted with no way to verify.

> Where is your chance of not being fucked? You can only be basing this on there (maybe) not existing tools today to persistently subvert the system through data-reading attacks. If that is true, that is only because the tool-makers havn't needed to do this yet. There is no good reason to think this step will trouble the rootkit tool-makers, once they need to take that step.

Its true that there is almost certainly data-driven exploitable vulnerabilities in the initial setup but as that code is tested they should become more rare. This early boot code doesn't have as much churn as the totality of the kernel (drivers, filesystems, etc.) so I think that in this limited subset of code that bugs can be fixed faster than they are created, although you can never be sure you've got them all.

> Maybe a somewhat similar kind of wishful thinking to what I had when I first installed an early rootkit-checker (that was maybe useful for a short time, a very short time, then the rootkit makers adapted). ;)

There are very clear problems with running such tools on a system which is already subverted. There are fewer problems if you can run these tools before the system is subverted. There is a continuum of probability that your system is subverted, lesser in early boot when there is very little security critical code and easier verification and higher the more of the system comes up, highest when you start running un-verified code. You'll have to balance the chance that there is an unknown vulnerability in early boot config code which subverts system startup before you can get a clean single-user mode up, presuming you build a path of verification all the way from the boot loader to your security checking tools.

Practical security for 2014

Posted Jan 12, 2014 10:09 UTC (Sun) by paulj (subscriber, #341) [Link] (1 responses)

I believe that computers cannot be made 100% secure, but things can be made more or less secure and that SecureBoot makes forward progress toward more secure. There are fewer attack paths and less trusted code as each step gets the chance to verify the next, it isn't all blindly trusted with no way to verify.

Ah, I see, you think you're reducing the amount of exploitable code. That's not what's happening though. As I explained before, what happens instead is that SecureBoot *elevates* the security sensitiveness of a *large* bunch of code that was never security-sensitive before (parsers and external event handling code in privileged code). To think that the system security will somehow be *increased* by this is utterly misguided. Particularly as we've seen, and continue to see, a large of parsing and event handling code (IPC) added to privileged code to make Linux more dynamic and reactive.

We simply do not know how to reliably write secure system software in C/C++, I think you'd agree. The LWN security page has been a testament to this. Even highly security sensitive software that gets much attention tends to see repeated problems (e.g. the kernel). That previously non-sensitive, non-attacked code is somehow going to be more secure seems highly, highly unlikely. And that user-space system software isn't exactly smaller in scope than the kernel either!

Anyway...

Practical security for 2014

Posted Jan 12, 2014 10:25 UTC (Sun) by paulj (subscriber, #341) [Link]

Oops, that code would have been security-sensitive before, for local exploits. Sorry. It just becomes even more of a target, for persistence.

So /non-sensitive/, /less-sensitive/. Etc.

Practical security for 2014

Posted Jan 12, 2014 10:19 UTC (Sun) by paulj (subscriber, #341) [Link] (1 responses)

This early boot code doesn't have as much churn as the totality of the kernel (drivers, filesystems, etc.) so I think that in this limited subset of code that bugs can be fixed faster than they are created,

This is just a lack of imagination. It just has to be code that will be automatically run at *some point*. Not just early boot code. It could be a privileged daemon that is intended to allocate some resources/permissions when a user requests. Rest assured the attackers will not limit themselves this way.

Further, I don't buy that early boot code has little churn in it. In Fedora we've seen a number of different re-engineerings of the initrd over the years. We've had a significantly more complicated PID 1 put in place, which speaks IPC with various things, some ultimately with paths for user influence.

You can have your belief that bugs in even just early-boot code will converge toward 0, but I still think this is incredibly wishful thinking and counter to general historical evidence, both in that there has been significant churn in boot code, and that the only reliable property of software is that it will be buggy! :)

Practical security for 2014

Posted Jan 12, 2014 16:00 UTC (Sun) by raven667 (subscriber, #5198) [Link]

> This is just a lack of imagination.

Maybe, I'm a deeply boring person 8-)

> In Fedora we've seen a number of different re-engineerings of the initrd over the years.

This churn is more in the programs which auto-generate the initrd and not the the part of the kernel which reads it.