Securing the Linux boot process

so good afternoon everyone hope you enjoyed your coffee it's my pleasure to announce to you Matthew Garrett Matthew you work in California for a company that makes a search engine and sells ads and a couple of other things and for many years I understand you have been interested in some time Furi ated about the Linux boot process but today you're here to talk to us about some glimmer of hope on the horizon so without further I do Matthew Garrett hi as Martin said my name is Matthew Garrett I'm a security developer at Google I do not work on any user products I'm also not speaking on behalf of my employers here nothing I say here is relevance to you know usual stuff do not use what I say is the basis of any financial investments I'm here to talk to you about boot security the security of the boot process and the reason I'm going to do this is because it's important and now obviously we would like to think that anytime any of us is up here talking to you they should probably think about they're talking abouts importance otherwise there's been some sort of terrible series of choices the reason the boot security is important is that if you don't have boot security there is no other security on your system every piece of meaningful security on a running computer depends upon the security of the boot process the reason for that is that if the boot process is insecure the boot process can tamper with every further components that is loaded it can modify your software such that it no longer behaves the way you expect it to and worse it can lie to you you can ask it did you just tamper with this software and it will say no even if previously it was supposed to say yes so we need a secure boot process in order to be able to have any worthwhile security as any later level of the operating system if you don't have boots security you can't trust your Colonel you can't trust your user land you can't trust your web-browser your bank details belong to someone else this just a theoretical thing it's very easy to think about this as you know just not a meaningful attack strategy but we've seen in the preface people did write codes that lived in the Master Boot Record of in the boot block of PC hard drives and could then disable various security features inside even modern versions of Windows and there's no way to protect against that once something has the ability to writes your boot block your boot security is gone the rest of your security is gone more advanced ones instead of directly modifying the boot block may modify the bootloader itself and this is more relevant on UEFI systems where you don't have a boot block as such instead the firmware looks at a set of variables a list of boot loaders and then picks a bootloader and loads that and we've also seen in the wild some number of tax that subvert the bootloader and this is also this has been seen in the wild on Apple Hardware where the boot loads was replaced and then when you typed in your disk decryption password that was stashed and then could be exfiltrated later on but we've also seen proof concepts and maybe not in the wild of attacks that don't attack the bootloader itself but go one layer further which is the init Rd the component in Linux systems that is responsible for the early Linux side of the boot process the init ID is a ram disk that contains various bits and pieces of interesting stuff such as say something's put a pretty picture on the screen to distract you from the fact that computers are terrible but also contains the code that does stuff like decrypt your hard drive because you can't do that with code that's on the hard drive because it's encrypted so the inners ID is responsible for taking user input or obtaining decription secret from some other source and then possum that's the kernel mounting your root filesystem and then executing the rest of it we've seen cases where people have modified the init rd such that when you type in your password again your passphrase is stashed somewhere and can be excellent rated later and to you it looks like a completely normal boot process so we look with in question well how do we fix these because this would be kind of depressing if I start there there is a variety of solutions that are used on a variety of platforms the embedded world is a fascinating place in this respect but I'm going to focus primarily on PC type systems and in for those the only solution that we currently have is UEFI secure boot this was a part of the UEFI specification added around 2010 2011 but it became notable to the Loess community when Microsoft required that it be present and enabled in all machines shipped in mid 2012 onwards if they were certified to run Windows 8 and the initial concern was that these systems would not be able to run anything other than Windows and the reason for that is that UEFI secure boot depends on the bootloader being signed now in the UEFI world executables such as your bootloader RPE files they're the same file format as is used by executive bulls on Windows and it just so happens that Microsoft already had a signing format for Windows executives so coincidentally the UEFI signing for that is exactly the same as the one used for Windows which is wonderful because it's not actually precisely specified and you can come up with incompatible implementations that are still spec compliant software is hard writing specifications is even harder anyway so you have a signature B firmware a list of certificates that it trusts and if an object has an appropriate signature and if the executive has not been tampered with then you will boot that object you can boot that object if it's either signed with an untrusted key if it's not signed or if the signature has been cut and pasted from another file and no good matches the file is attached to you were tend to execute it and you just get an error telling you that you can't do that so this sounds great the boot security problem is then solved we're able to stop now and it is in as of now it is 150 seconds until happy hour starts at the gin bar across the rows unfortunately the problem is not actually solved which is why I'm here telling you that things are bad but I have a plan as opposed to tell you that they're fixed so yeah obviously the problem is not entirely solved because going back to one of the attack vectors I mentioned earlier in it's our DS arnott side they're not PE objects they're not executive all UEFI secure boots and those nothing about them from a UEFI spec perspective they're merely an implementation detail of the bootloader they are things the bootloader handles outside the spec so the bootloader could deal with signatures on them but why and obviously as I mentioned init aunty's do a bunch of meaningful security stuff but we can't easily just sign them because they contain that local configuration they're built typically on the local system users do things like choose which artwork they want to display because users have opinions and so we can't easily say okay the init RD is going to be built by your distribution and then we're going to put a signature on this and then we're going to have a bootloader that is able to both verify UEFI style signatures and is also able to verify arbitrary detached signatures for entities because I'll do all that and then we're into well now we're on at least three layers of crypto and we're having a bad time so we can circumvent all of this in theory and just step on too well how about we use a completely orthogonal piece of security technology in the form of a trusted platform module or TPM TPMS are small cryptographic devices that sit on your system motherboards they are very slow they are relatively inexpensive and they're not particularly good at anything that you would normally want to do when you say oh I have a hardware crypto device on my other boards you think excellent I can run my crypto on there and it will be faster and it will not be faster the reason TPMS are interesting though is that they don't they're not under the control of the system processor they can hold secrets they can contain information and they can make decisions based on that information and your CPU can't directly interfere with them they're independent devices with a very well-defined communications framework one of the features of a TPM is a set of registers called platform configuration registers and these registers just contain hash values you pass a hash value to the TPM and it incorporates that hash value into the value that's in a PCR generates a new hash and then stores that whenever you reset your system all the PCR 0 as you boot each component of your boot process hashes the next component and passes that to the TPM so the TPM contains basically a list of cryptographic hashes that describes your boot process and this is called measurements you are measuring each component in turn the TPM has copies of these measurements now in itself that doesn't seem particularly helpful but CPM as I mentioned is an independent device the TPM cannot prevent your system from booting system with the TPM you can still boot whatever you want to but the measurements that go into the TPM as a result will be different remember what I said the TPM can make decisions about what to do based on various things one thing a TPM can do is decide whether or not to release secrets based on the PCR values so you have a PCR that contains measurements of the firmware you have a PCR that contains measurements of the drivers for any plug-in devices you have a PCR the contains measurements of the bootloader you have a PCR that potentially contains a measurement of the init Rd and if all those values are correct the TPM can decide to release a secret so great we have the bootloader measure the init Rd and then we put the disk decryption key into the TPM and then when you boot if the PCR values match the TPM hands over the secrets to the operating system your disk gets unlocked you don't even have to type your password and your system boots in a completely secure way if anybody tampers with your init RZ the measurements change and the TPM refuses to hand over the secret your disk doesn't get unlocked everyone is a winner up until the point where through a unfortunate confluence of decisions you lose all your data because if any of those values change if any of those pcs change the TPM stops handing that secret over if you do a firmware update the firmware values change if you update your bootloader the bootloader value changes if you rebuild your init RD the init Rd value changes and if in any of those cases you fail to update the PC R the acceptable PC R values in the TPM the TPM will no longer hand your secret over and getting back into a recovery state may be impossible so relying on fully measures as in measuring every single compose so the boot process is really really hard fortunately Microsoft saved us so thank you Microsoft that was very helpful we appreciate that a great deal Microsoft realized that this fragility was a problem presumably because people turns this functionality on in Windows and then kept phoning Microsoft's to ask how to get their data back because while it's difficult for us it turns out it's also difficult for Microsoft and Microsoft have thoughts about this hard and Microsoft does employ a large number of smart people and Microsoft decided that well the easiest way to handle this was to take advantage of the fact that currently secure boot and trusted boots this TPM based thing were completely orthogonal and unrelated and instead tie the two of them into each other make a measurement process that takes advantage of the properties of secure boot remember in secure boot the only code that will be booted is stuff that's signed but you also want some degree of guarantee that someone has not tampered with various other bits of the boot process such that they are able to circumvent the security guarantees of the science material so in this mode rather than measuring the files you measure the signing keys that we used in the boot process and think about it if you signed something yourself you know that an attacker can't Stamper with it you know that the TPM measurement if the PCR value is correct then that means it was signed with your signing key as long as your signing key is under your control then the TPM is in a good state the boot process is in a good state it boosted something that you signed therefore everything's okay the actual content could be anything you signed it so as long as you scientists or as long as someone you trust like your distribution scientist you're fine but in in sardis outside so we haven't actually solved much here as yet if you still incorporate the measurement of the in tardy everything still breaks whenever the innit Rd gets rebuilt and on Debian that's something that happens because it's a day as far as I can tell you install a package you're in a tardy gets rebuilt it I installed LibreOffice base Rd getting rebuild and yeah some components got upgraded and it's he came home that goes into the in tardy and therefore it's been rebuilt as well wonderful this makes things difficult so how can we apply this to init our DS while still allowing user configuration which is apparently important because Linux is about choice more useful after that systemd since it includes literally every piece of software anybody could ever conceive ever includes something to solve this problem system D includes something called the system D boot stub the system D boot stub is not the same as the system D bootloader even though some of the codes it shares and even though it is quite understandable that you might think they're the same thing they are not the same thing the system D boot stub is a very small efi executive all you build it and if you run it it then does nothing or crashes so that's a good start but you use AB copy to embed a kernel and an init Rd into this and then when you run it it relocates the kernel and the inner tardy and then jumps into the kernel so you have a single image and then you can sign that and that single signed image contains both your kernel and your init Rd and more than that it can also contain the kernel command line so you can embed a lot of stuff in there under a single signature and then you just it's a valid efi object so you can run that from anything that is able to run a Santa GFI object which includes other boot loaders which includes the UEFI shell you can point the firmware directly at this and you don't need an additional bootloader at all the firmware will just jump directly to this verify the signature and then run the kernel and it is Rd with that command line but in it are these contain local information and we can't expect average end-users to sign their own stuff all the time end-users are not security experts it transpires years of practice have taught me that end-users are not fundamentally good at cryptography and I do not blame end-users for this I should emphasize that we have made a very complicated set of things and then asked end-users who really would prefer the computers mostly just go away entirely that if they don't understand this stuff it's their fault and that's a terrible thing to tell users and it's our fault we should do better we can't ask users to sign their own stuff so we need another solution thankfully I say thankfully a lot I have a lot to be thankful for thankfully you can pass multiple inners Rd images to the kernel and in it Rd is just in compressed cpio archive and CPI OS I don't even know what CP ru expands to it's something from the past it predates me yeah key points out that cpio existed before I was born and I believe that to be true cpio will probably be there after I die over at Lee thereafter we all die cpio will outlive all of us be careful when you're inventing file formats that's all I'm saying a nice thing about CPI o is that it's a very simple format and so you just create a cpio archive and then if you just smash it onto the ends with another CYO cpio archive the Colonel's actually able to just work through one and then work through the other and unpack each of them in turn so this takes the form of the kernel mounts a magical root surface Ram disk and then decompresses and extracts each in its Rd image in turn into that the nice thing here is that each of them will overwrite the previous one so the goal here is to make it possible to have a user controlled in it Rd that is not signed but to still have a trustworthy boot process the trick is that if we design our in sardis such that configuration and code can be cleanly separated we can unpack and in its Rd that contains the configuration first and we can unpack another in its Rd that contains the code afterwards and on top and if an attacker attempts to put code in the configuration insardi the kernel will just over Isis with the contents of the code in its Rd so if we embed the code in its Rd in the signed image we can then provide an additional data configuration insardi and not have to worry about any security implications I say this this is obviously a lie right now this is not how the world works one of the ways in which the world doesn't work like this is that people think oh configuration and the way we do configuration is that we set environment variables in bash and then we'll just import that file that contains those environment variables and yeah you're not actually that that's not data anymore that's code your configuration format is code this is bad so first of all we need to just fix the entire world to stop importing yeah anyway so it turns out that with not too much work this is viable and not too much work may involve completely replacing way that Debian generates init sardis again which is I think at least the third time it was happened in so I might be using Debian that might be using Debian 20 years almost so that's not too bad I hear that Debian users really enjoy change anyway let's assume that we can solve that because it's code is this is a simple technical problem and simple technical problems are easy to solve especially interview but the kernel command line is also security sensitive because it seems like no D can ever think of a good security feature that someone won't want to turn off and the kernel command line lets you turn security features off so for instance hmm the iommu exists in part to prevent someone plugging a dmae capable device into your machine and then just extracting old secrets from it so your disk decryption key is stored by the TPM but is copied into RAM to actually work while the system is running because the TPM is not fast enough to decrypt your hard drive in real time the system processor has to do that you can turn the IMU off from the command at the command line and that means that someone can then boot your system with the IOM you disabled and then dump your disk decryption key and then steal your drive and guess what your data even if they don't know your passwords so again kind of bad but thankfully again the kernel saves us once more because if you have the same parameter on the kernel command line multiple times the last one wins usually it's possible for people to break this presumption because this isn't actually specified software again is hard but we can have a command line that is inside the signs image that turns on all the relevant security features and then we can append that to whatever command line the user provides and we need to do a bit of additional filtering because if the user types in a command line that has space - - space then the kernel will stop interpreting anything after that as part of its command line and will instead pass that in it all I'm saying is that if we can invent a time machine maybe we should do some things differently but what's the point of all of this what is the point of having a mechanism in which we get to a state where the TPM has a meaningful measurement of stuff we boosted without being too fragile what is the additional security that we get and there's a bunch of things like as I mentioned the disk encryption keys can be stored there but you can also get proof of device state and I wrote a piece of software called TPM TOTP which is like 80 OTP two-factor authentication setup except instead of you proving yourself to a remote system by typing a number from your device into the remote system your a laptop boots if it's in a valid state it can then get a seed from the TPM which the TPM will not otherwise give it and it can then based on the current time show you a six digit number and you can then compare that to your phone see if the numbers are the same and if so you know the system is in a secure state and you know that you can type your passwords into it rather than your passwords being typed into a keylogger something I've been thinking about this week by virtue of having been given one of the tomu USB micro controller things is you could do the same thing but instead of having these six digit number you could have a conversation between the tomu and your laptop on boot so the TPM will hand a hand proof of its state over to the tomu and then the tomu can blink an LED if it verifies that you boot it in a secure state so you can see the blinking lights and you can know that it's safe to type your password in so we have the ability to prove that your device is in a trustworthy state before you tell the system anything we need to remote ISO station which is in one sense a way to brutally restrict what users were able to do with their systems for the benefit of corrupt massively unethical cast list organizations or alternatively is a great way for you to know that the machine that is trying to connect you on network is a machine that should be trying to connect your network and is not say a tool of an unethical massively corrupt capitalist entity it's technology we can use it for good or evil remote excitation you prove your device States to a remote site and the remote site makes a decision based on that and that can be useful free for us if circumstances say in a cloud set up the compute nodes can prove to the controller that they booted the correct operating system that they were not tampered with and you can look at that and make a decision as to whether or not you're happy to pass user jobs to those systems or whether you think this systems now in an untrustworthy state and you can securely provision secrets to remote systems one of the problems you have if you want to get stuff system set up in the data center is how do you get your secrets onto those systems now the usual way is you send someone out there with a USB stick that contains the secrets and once the machines installed they provision the secrets that means you need to pay for a someone to go and sit in a data center waiting for machines to install and that isn't fun for anybody you can put the secrets on the machines in your location and then can send the machines out to the data center and then anyone who intercepts them in the wet on the way is able to extract your secrets or you can just Yolo it and racket in the data center and then when the machine comes up assumed that it was provisioned to your instructions and not to someone else's instructions and then copy your secrets to it and assume that they're secure instead you can get the Machine you can record the TPM information or you can potentially even get your vendor to provide you with the TPM identity in advance you can ship that system of the data center guess it's installed and then it can attest back to you hi I'm this system I'm now running this software and can I please have some secrets and you can create graphically verify that and then you can encrypt the secrets with a key that is associated with the TPM on that device and then it's impossible for any other device decrypt those secrets only the machine that you are sending those secrets to will be able to decrypt them so you can securely provision systems without having to have any trusted people touch the machine so I told you about some codes I've written and I'm going to demo it because I'm a fool Q mu re Q mu yes thank you Wayland those of you who have not seen that the UEFI shell before will understand that it looks kind of like dolls it looks really like Dossett but he's really it's got back slashes in path names and and yeah C D doesn't behave the way you expect it to and it does rub them LS although LS works as well because why not anyway so I have here boot i'll see if i as you can see is his 22 megabytes big which is quite a large executive all the reason it's large is that it contains a kernel anton insardi and a command line stuff so i used to boot das efi and i'm going to do root equals yeah sorry b2 and then I'm going to ah I'm going to circumvent security by doing in this equals in bash and a good measure I'm going to disable the iommu and also I'm going to loads I'm going to load an init Rd that in this case actually doesn't contain anything evil but could contain something evil so let's see what happens that's good and oh it didn't run bash in fact it uses entirely so what's in the command line so we see that it has removed the in its equals bin bash from there and it's also appended Intel IO mu equals on so that the system boozes with the iommu enabled so yeah my all my attempts to circumvent the boot process security there were just disabled and the system booted into a secure state so good my demo works thankfully so while I'm at this I'm also going to quickly know right there so I'm currently in on this window is this large enough for people to read yeah at the back there any wave your arms in the air if it's bad okay better okay you're happy I like people being happy so here I am in slash this slash kernel slash security slash TPM 0 which is one of my favorite kernel directories it contains these files and these are copies of the log that is kept by the TPM during the boot process these contain everything that the CPM measures during boot and the binary one is the interesting one and is in binary so it's not actually very readable so I'm going to pipe it through hex dump and we can see ok there's um I really like seeing the word debug there that's concerning some boot guards isn't Intel technology we're at the management engine which is Cure I've been asked to stop saying mean things about the management engine so I'm not going to the management engine measures the first chunk of the system firmware against the TPM and then optionally verifies the signature on it so if any one tampers with the system firmware either the system doesn't boost at all or the measurement changes so if your based are if you're basing your secret policy your TPM policy on the firmware PCR values as well as the PCR values then boot guard makes this more reliable it because God does this before the CPU starts executing any of this code further down we've got various bits of configuration and then here we have measurements of the secure boot policy and you can see you can tell because it says secure boot and then here we have it is measuring the secure boot key database so as we scroll through here you'll see a bunch of keys belonging to my system vendor and some Microsoft and well yep all of this looks kind of like an RSA key and RSA certificate and it's you'll see the marry top one appear in multiple times because firstly it's there as this is the copy that's in the firmware but then also this is the copy that was used to verify the signature on my bootloader and then we have a whole bunch of others yep there we go I think this is the one that is used - um this one is you don't need to care like this is just for local color and then it loses my boot logo so there we go and if I go back [Music] right and here are some github repos that contain various bits of relevant codes now one thing per system D boot stub as I mentioned is not a bootloader in D traditional sense it's just a way of executing a kernel you still potentially want a bootloader or UI purposes and give the user a way to do things like edit the command line grub is still the most fully feature it's one of those on x86 the verifier TPM module adds full measurement support to grow up so grub will then not only the system firmware it will measure the system D boots dub but grub will also measure that into other PCRs and can also measure other bits and food configurations so if you want a more complex policy if you are willing to deal with the fragility yourself you can use this and you can have a much more interesting fine growing policy and then the system deep support for multiple in sardis and command line the pending is in that repo I not try to push those upstream yet and then TPM TOTP is the tool I mentioned previously for letting you verify system boot state by verifying that these six digits your computer gives you are the same as the six digits that your phone is giving you so we have seven minutes left does anybody have any questions thanks Matthew I have a socket in my motherboard for a TPM but whenever I go to look for something to put in it everything looks incredibly shady and not something that I'd really liked by all grades isn't it yeah can you recommend No thank you so the way I solve these problems is that I get you reputation for supporting TPMS on Linux because I compete some among the terrible life choices I've made and then TPM vendors just send these things to me and then I so I have a supply of TPMS from all kinds of interesting places with Chinese TPMS TPM to is wonderful because it supports using different hash algorithms so you have TPMS that do sha and you have TPMS that do the chinese equivalent of sha and you have TP ons that do the Russian equivalent of char so you can pick which country you think is least likely to have a both a backdoor cryptographic hash algorithm and want you to have a bad day and you can get one of those TPMS but so the pin out of TPMS is standardized the sockets that you plug them into is less well standardized there's basically a large 20 pin header that's just two rows of ten that's about this is not really helpful for anyone I'm sorry that's a couple of inches long oops I've been in America too long about four centimeters five centimeters long and then there's a much smaller one you can get adaptor boards to convert between them and occasionally you can find TPMS on these boards on Amazon I don't know if it helps you in Australia probably not it'll arrive here in 15 years or something so no I don't have good recommendations I'm afraid sorry but try Amazon thank you very much for your talk Matthew clay out vendors and lining up to do these sorts of things with their environments um is there anything that's really working there yet and what suggestions or what things could they do to get us to that point vendors as in distributions more like if I was putting something up on AWS and I want to make sure that we are lying and the hypervisor etc is your has support for secure boots and also does TPM support so I believe you can set something like this up on Azure I cannot comment on other cloud providers how do you compare with the the Circa boot kind of status on a desktop and a compared with the one country having and I think what is supported and enjoyed like UEFI secure boots oh so yeah the Android verified boot process is quite different initially cannot change because this fix that's one of them yeah so on certainly on nexus recent Nexus and pixel devices and potentially on other unlockable devices you can change the trusted signing key but right now I honestly don't know whether you can do the sort of combination of the verified boot and a trusted food thing I believe that aspects of safety net on Android are - and they said something similar to remote ISO station but I don't know the details myself I'm not on the Android team you know the question is why the Android didn't use the TPM instead of using the others like just oh so what's your view this is complicated I again I can't Steve the Android team not on the Android team the embedded world in general has not tends it to you TPMS because you have some level of crypto functionality on the SOC and adding an additional TPM would be additional cost I think the in terms of implementing a spec compliance TPM the only arm devices I've seen that do that were Windows Phone Windows CE devices where they were booting no into C Windows RT which used a TPM for the secret management but even though those were armed they basically looks like pcs for this purpose so outside that I it's just not so thinking about it well seems to do maybe quickly to fill in Matthew I have a very short question when I said that the computer itself is going to pop up a six digit number and then I can verify the integrity of the device what you've shown earlier about the init the the kernel command line being reverted to a secure state does is that what ensures that I can't just write malware that pops up a six digit number to make you believe that a well you can pop up a six digit number easily but it won't be the right one would be a different six digit number thank you umm I first I'd looked into TPMS back in 2010 2012 something like that and I developed the reflexive Association that they are user hostile freedom hostile potentially and to run screaming has that improved nobody has as yet deploys TPMS in a user hostile way in others but it turns out that it's very difficult to build a real remote Association chain that gives you certainty that the user is not running tampered software that's going to circumvent whatever you are trying to do and in the face of okay so the easiest way to get around remote South Station boot your system the TPM on your motherboard now has values that record the fact that you've booted a active copy of an operating system that will gladly say I implement the RM and will then dump the contents of everything to disk anyway so at that point the remote site says no you can't speak to me get another TPM for him safe Amazon who I believe may sell them plug that into you and then just hook that off your parallel poles or something just build a USB adapter for it and then program good values into that TPM and then when the remote test station query comes in direct it to the one that you programmed instead the one of your motherboard and you don't need if the idea is to stop people dumping stuff then if that's the security model you've just got a way to completely circumvent that given that this is possible it's not usually being used for DRM it's more being used for cases where you want to verify that the machine has not been compromised without the users knowledge so it's cases where my laptop has not been compromised while I'm try to get on to my company's VPN for instance if I'm deliberately trying to circumvent my employers access controls yeah I can do that so I think arousal time with you yeah I think we're out of time thank you very much for your enticing and hope inspiring talk you

Channel: LinuxConfAu 2018 - Sydney, Australia

Views: 5,620

Rating: 4.8775511 out of 5

Keywords: lca, lca2018, #linux.conf.au#linux#foss#opensource, MatthewGarrett

Id: ywoMSwvxZo4

Length: 45min 42sec (2742 seconds)

Published: Wed Jan 24 2018