Feature Request: Add prior kernels to dbx about sbupdate HOT 15 CLOSED

Guys, please don't do this here. Keep the conversation civil and focused.

from sbupdate.

Hi, sorry for the delay.

After reviewing the discussion, I think that the particular attack scenario does not justify the added implementation complexity.

I suggest to use a hard drive password to prevent access to the EFI system partition. Many hard drives can use hardware encryption. Alternatively, you can keep ESP on a flash drive.

Note also that the Database Key (db) itself can contain executable hashes, and then there is no need for a public key and blacklisting at all.

from sbupdate.

I don't think this would be useful in practice. If older kernels are installed on system then it can be assumed they may be still useful for users. If the aren't installed then there is nothing to protect against.

If you don't want to boot older kernels then simply remove them. As Arch Linux always overwrites old kernel with a new one this feature would be useless for vast majority of users and not worth complicating the code.

from sbupdate.

The style of attack where this sort of protection is useful is called an Evil Maid Attack. The idea is that someone with periodic access to the unpowered device (such as a maid) could copy a signed kernel from the ESP and then wait. Eventually a vulnerability will be found in that kernel, because all software has bugs. The computer's administrator will hopefully patch the kernel with a new fixed copy.

However, since the evil maid has retained a signed copy of the older kernel, they can load it back onto the computer and exploit the vulnerability. Typically researchers will publish proof of concept exploit code. They will withhold it for a period of time to allow everyone to patch, but they'll eventually release it. The evil maid is patient.

To protect against this, older kernel revisions should be blacklisted once the administrator no longer plans on needing them. The blacklist needs to be retained until a rotation of the DB key happens which makes all prior signed images invalid for booting.

from sbupdate.

Could you provide example vulnerability this will protect against? There's lack of details how your proposed fix helps against described threat scenario. Evil Maid Attack doesn't target vulnerabilities in kernel (or any other software vulnerabilities).

If there is no disk encryption and attacker have access to hardware then there is nothing to protect against. If there is disk encryption then after switching kernel it won' t be possible to boot the system because modules on the disk won't match with the old kernel (I assume the point was to trick victim into running old vulnerable kernel and attack it remotely after boot).

from sbupdate.

I can certainly provide a more concrete case, but let me first start generally.

Encryption is somewhat orthogonal to secure boot. At first glace full-disk encryption seems impenetrable but it doesn't protect against all the vectors that it initially appears to protect against, such as tampering*. It helps protect against some vectors that overlap with secure boot and others that don't, but it's definitely no silver bullet. Additionally, there's no widespread vendor support for encrypted storage in UEFI, meaning the first UEFI executable will realistically be in cleartext, whether it's the Linux EFI stub or some more complex loader. Whatever that first binary is, it will have bugs. It's oft said (and I believe Greg KH is on the record as saying) any bug can be a security bug, if someone tries hard enough. There's no functional difference between buggy software and malicious software in practice and the DBX is the intended mechanism to revoke signatures for malicious software. So in general, software should be revoked once it's no longer in use.

Now for a more concrete case. Here's a straw man scenario, don't poke it too hard.

A journalist utilizes secure boot using their own PK, KEK, & DB keys and stores at least the DB key on the same device as is being protected (such as how sbupdate operates). They shut down their computer each night when they leave the office. (If they don't shut it down, there are simply other attack vectors, just not the Evil Maid style of attacks we're talking about here). An adversary wishes to compromise this machine. On night number one, the adversary removes the journalist's hard drive from their computer and takes a full dump of it's contents. After replacing it they leave. They now have an arbitrary amount of time to review it.

In case A, the boot partition/files are stored unencrypted (even if root is encrypted). In case B, the UEFI executable is in cleartext but all subsequent boot files are encrypted. At a minimum, the adversary is likely to discover the version of the UEFI executable since most programs embed this information directly in the program. Now, they can either start their own dissection of program for vulnerabilities or they can wait for someone else to do it for them. If they're lucky, the program is out of date and they can casually google for remotely exploitable vulnerabilities. Linux has had a number CVEs in the last decade that can be attacked remotely and can lead to arbitrary code execution. Consider also that the adversary can leave devices attached that may go unnoticed, since they may be behind a tower or inside a case. So the network is not the only attack vector. If the program is up to date, they can just wait. Eventually an exploitable bug will be found, it just depends who the adversary is and what their funding is like.

When an exploit is ready, they return on night number two (not necessarily the next night, but it could be) while the computer is shut down. They take a new dump of the journalist's hard drive since, depending on how long it took to find a vulnerability, the contents may have changed. They restore their old copy to the drive.

In case A, they can have two kernels on the boot drive. One is the original, which is signed and unmodified, but is exploitable. The second is one of their crafting which can be built with all required components to boot the system embedded. When the journalist boots their system, the exploit will be trigger and it will chain load the additional kernel they've installed. This additional kernel will finish the boot process and will contain whatever backdoors or monitoring software they desire. It can even delete itself from the disk to cover it's tracks. Or sign itself with the (now accessible) DB key and replace the original.

In case B, they take a slightly different approach. They don't know what the other boot files beyond the first cleartext UEFI executable contain, but they don't really need to know that. In this case they won't end up fully booting the computer. When the journalist boots their computer, the original (signed, unmodified, exploitable) kernel runs and is then exploited. The exploit prints to the screen the contents that the user normally sees when they boot. The journalist enters their disk encryption password into the compromised kernel/initramfs and it's immediately transmitted to the adversary. Since they took a copy of the journalists drive when they returned on night number two, they can use this disk passphrase to decrypt it and view the full contents. Whether or not the compromised kernel finishes the boot sequence is irrelevant as they've achieved their goal.

Note that this package does not detect nor enforce disk encryption (of /boot nor of /), meaning that one cannot exclude case A out of hand. However, as explained above case B doesn't stop a malicious actor anyway, depending on their goals.

This is absolutely a straw man and we can poke it all day long**. Schneier's law says we can go back and forth until the two of us agree on a system that we can't break, but it doesn't mean it's unbreakable. Defense in depth is the best strategy to defend against unknown attacks. Adding blacklisting of old (read: exploitable) kernels is a defense in depth mechanism. The UEFI specification authors knew this and included a mechanism specifically for it.

The goal of this change is to make it harder (not impossible ***) for an adversary to bypass the benefits that secure boot is trying to convey. It does this by limiting the list of valid signed software the system will boot. In it's current form, sbupdate allows any kernel ever signed at any point in the past to be booted. This update limits the list to kernels the system administrate would reasonably want to boot (current + 1 former kernel) which ideally will be kept up-to-date against discovered vulnerabilities.

As coded in the pull request, it's an opt-in option meaning there would be no change for existing or new users. This seems like a fair compromise between security and stability since UEFI implementations (notoriously) vary from one to the next and the rough edges will likely need to be polished. A separate discussion could be had later on about whether to turn it one by default or not, but it's worth making it available to those who'd like to try it.

* This wiki page is a good overview of the thought that has been put into this. It surprises many people that full disk encryption does not protect against tampering. Notably, blocks (or the whole disk) can be replayed because authenticated encryption is not used and filesystem characteristics can be leaked, especially if the attacker can observe the drive several times to record what's changed.

** The first jab I'd take would be to introduce TPM-based disk encryption in to case B, so that the user needn't manually enter a disk passphrase, making it harder to exfiltrate the disk encryption key. Again, I'll point out that sbupdate doesn't enforce TPM-based encryption. However it doesn't mean the adversary is defeated. They just need to shift to social engineering tactics. Users are less security conscious when they're in a rush and most TPM-based encryption schemes have a backup passphrase-protected copy of the disk encryption passphrase for emergencies. The adversary has the luxury of timing their attack on a day when the journalist has an early meeting requiring the laptop. They can ensure the journalist is running late. They can model a fake kernel panic / reboot and then prompt for the backup passphrase under the guise that there's been a disk error.

*** A simple bypass: replace the motherboard with another that doesn't have secure boot enabled :)

from sbupdate.

Encryption is somewhat orthogonal to secure boot

Nobody said otherwise so this long out-of-topic paragraph wasn't necessary. The point was that without encryption, securing boot process is pointless for physical attack vector because attacker will have unlimited amount of targets in userspace like systemd or bash.

In case A, the boot partition/files are stored unencrypted (even if root is encrypted). In case B, the UEFI executable is in cleartext but all subsequent boot files are encrypted

I think we should clarify some things for this discussion because you are constantly talking about signing/downgrading/blacklisting kernels and treat other boot files separately while sbupdate doesn't sign the kernel.

It signs single efi executable which consists of kernel+kernel cmdline+initramfs+splash+os version. So if we could replace "kernel (+other bootfiles)" with "efi executable" it will make this discussion clearer. That also means case B totally irrelevant because you can't encrypt efi partition where efi executables are stored.

In case A, they can have two kernels on the boot drive. One is the original, which is signed and unmodified, but is exploitable. The second is one of their crafting which can be built with all required components to boot the system embedded. When the journalist boots their system, the exploit will be trigger and it will chain load the additional kernel they've installed. This additional kernel will finish the boot process and will contain whatever backdoors or monitoring software they desire. It can even delete itself from the disk to cover it's tracks. Or sign itself with the (now accessible) DB key and replace the original.

How you put and run exploit into signed (and trusted) efi executable environment? I asked about practical example of such exploit. You made a lot of generic commentary without describing how it relates to sbupdate which is what I wanted to know. Please be more specific. Attacker can load shell in initramfs and execute exploit from usbdrive themselves but how would they do this automatically for victim where even secretly attached usb drive isn't auto-mounted?

The first jab I'd take would be to introduce TPM-based disk encryption

I would recommend more reading about TPM exploitation. This may not be concern for average Jane but it fits perfectly into scenarios you described. You absolutely don't want using TPM for disk encryption for defense in depth as you say.

As coded in the pull request, it's an opt-in option meaning there would be no change for existing or new users. This seems like a fair compromise between security and stability since UEFI implementations (notoriously) vary from one to the next and the rough edges will likely need to be polished.

It complicate the code which has maintenance costs. If it would bring some security benefits then it could be treated as compromise. I still don't see such benefits and I would call it security theater (if you like buzzwords) - here's wiki page (if you like them as well) .

Threat scenario you described is very loosely related to sbudate and lacks concrete. Basing on what you wrote I'm not sure if you fully understand how sbupdate works.

from sbupdate.

How you put and run exploit into signed (and trusted) efi executable environment?

This appears to be the root of the misunderstanding. The attacker is not adding an any vulnerabilities into any signed executables. The vulnerabilities are already present in the form of common bugs. Any sufficiently large piece of software (such as the kernel) is bound to have bugs. Some bugs (especially buffer overflows) can become security issues.

A quick google yields several remotely (via the network) exploitable security vulnerabilities that lead to arbitrary code execution: CVE-2015-8812, CVE-2016-10229, CVE-2014-2523. These don't require the attacker to install any files on the device, they just attach to the same network and send specially crafted packets containing code to execute. Network-exploitable CVEs get all the media attention, but for this scenario PCIe, USB, etc. would all be viable vectors as well because they're all probed during boot.

You do not want to be running kernels that are known to have these vulnerabilities in them, but if you've been running with a secure boot setup and update frequently you've likely signed dozens of kernels in the past. Those kernels have bugs: some known, some not. The DBX is the mechanism by which you say "I used to want to boot these kernels, but I don't want to bot them anymore - they're outdated".

from sbupdate.

Also forgot to mention that it isn't just linux vulnerabilities that are in play, any vulnerabilities in anything in the initramfs are in play as well. But those typically have a smaller attack surface given their role. udev and dmcrypt both interact in fairly general ways with hardware/block devices that are under the attacker's control though so they might be interesting as well. The moral is the same though, you don't want to run old software because it might contain exploitable bugs.

from sbupdate.

This appears to be the root of the misunderstanding. The attacker is not adding an any vulnerabilities into any signed executables.

Again, nobody said that so this is another straw man you are arguing against. Existence of vulnerability is one thing, exploitation of it in particular environment is another. I asked about the latter.

A quick google yields several remotely (via the network) exploitable security vulnerabilities that lead to arbitrary code execution: CVE-2015-8812, CVE-2016-10229, CVE-2014-2523. These don't require the attacker to install any files on the device, they just attach to the same network and send specially crafted packets containing code to execute.

This requires victim connecting to those networks. Initramfs doesn't even have networking support in default setup.

Network-exploitable CVEs get all the media attention, but for this scenario PCIe, USB, etc. would all be viable vectors as well because they're all probed during boot.

So is the actual threat scenario that attacker downgraded efi executable and plugged something to computer port which will the cause arbitrary code execution during boot and victim will run this setup without noticing (this again assumes that initramfs is able to load such device which isn't guaranteed)? Do you have any CVE examples of such kind? This is what I'm continuously asking for.

I wonder if installing hardware keylogger this way which wouldn't need any present vulnerability is more realistic attack vector (and one which dbx blacklisting doesn't protect against).

from sbupdate.

Initramfs doesn't even have networking support in default setup.

You can't assume anything about the user's setup that sbupdate doesn't enforce. There is an Arch wiki page detailing how to use dropbear as a means to unlock a luks-encrypted rootfs.

So is the actual threat scenario that attacker downgraded efi executable

Yes.

... and plugged something to computer port which will the cause arbitrary code execution during boot

This is one option the attacker has.

Do you have any CVE examples of such kind?

CVEs don't document attacks, they document vulnerabilities. Sometimes vulnerabilities are so bad you only need one to achieve your goal. More often you need more than one, each vulnerability chaining into the next. So no, I don't have a CVE documenting this exact sequence, but such a thing will never exist. More likely would be a Blackhat/Defcon talk where they demo it.

I wonder if installing hardware keylogger this way which wouldn't need any present vulnerability is more realistic attack vector

Absolutely. As I mentioned earlier defense in depth is extremely important. You can't just protect against a single vector. The maximum chance of success for an attacker is if they try multiple vectors.

from sbupdate.

Microsoft currently maintains a dbx for software signed by their secure boot keys. Here's a MS knowledge base article for a windows update where they added new hashes to their DBX proactively. I didn't read too deeply into it because they don't typically detail much about the vulnerabilities that have been discovered. But maybe this will help dispel the thought that this is "security theater". The DBX that is preloaded into the UEFI firmware on one of my machines has 76 entries in it.

It would be a separate feature request to install these entries as well. They're only needed if the user has multiple DB keys installed. If they only have their own DB key installed, then these hashes are not required as the binaries aren't signed by the user's DB key so they wouldn't be authorized to boot in the first place.

from sbupdate.

You can't assume anything about the user's setup that sbupdate doesn't enforce. There is an Arch wiki page detailing how to use dropbear as a means to unlock a luks-encrypted rootfs.

There is a long way between no network access in initramfs default setup and connecting to attacker controlled network. You have to make A LOT of assumptions about victim behaviour to make this possible.

This is one option the attacker has.

And the other is? I'm trying to provide some realistic scenarios based on your very generic descriptions. It would be much easier if you would describe those scenarios yourself.

CVEs don't document attacks, they document vulnerabilities. Sometimes vulnerabilities are so bad you only need one to achieve your goal. More often you need more than one, each vulnerability chaining into the next. So no, I don't have a CVE documenting this exact sequence, but such a thing will never exist. More likely would be a Blackhat/Defcon talk where they demo it.

So I asked about CVE for vulnerability which allows for arbitrary code execution from kernel by merely plugging usb device to system. I heard only about ddos/crashes which aren't relevant here. I'm sure if such thing existed in the past it would get CVE. I wouldn't mind if you can link Blackhat/Defcon presentation.

Absolutely. As I mentioned earlier defense in depth is extremely important. You can't just protect against a single vector. The maximum chance of success for an attacker is if they try multiple vectors.

What you propose here is protecting against single vector (downgrade+exploit). With physical access (on multiple times) there are unlimited amount of attack vectors to choose. Why attacker would want to go for harder task if they have much lower hanging fruit then?

There are 50 windows in the building, you chose one and said "they will go in right there we must secure it!". After that maybe some people will start believing that security level was raised (there are just 49 unsecured windows left) but in fact it wasn't.

Microsoft currently maintains a dbx for software signed by their secure boot keys. Here's a MS knowledge base article for a windows update where they added new hashes to their DBX proactively. I didn't read too deeply into it because they don't typically detail much about the vulnerabilities that have been discovered. But maybe this will help dispel the thought that this is "security theater". The DBX that is preloaded into the UEFI firmware on one of my machines has 76 entries in it.

I know for what DBX is used by MS for. It's used to blacklist signed (by them) efis which allow to break secure boot. It isn't used to blacklist old windows versions. Similarly neither fedora or ubuntu use DBX to blacklist their old kernels. I didn't call what MS does security theater. Except using TPM for storing encryption keys I didn't comment about anything you mentioned in general terms. I called security theater only your idea in relation to sbupdate project. Most things you wrote may be perfectly applicable in other environments but this isn't relevant for this discussion which is only specific to sbupdate and nothing else.

from sbupdate.

Look, a pull request is a donation of my time and energy. @andreyv can take it if they want it, but I don't have the time to go find specific CVEs for you. There's an easily searchable database you can look though, especially when USB is just one option the attacker has, not one they have to take.

The pull request is there for anyone who wants to use it, so I've achieved my primary goal. Having it upstreamed just helps ensure it keeps working, which would be nice thing for future users, but if you're going to be bullheaded about it then it's not worth the effort.

If you can agree that old software is buggy and buggy software is dangerous, then the benefits of this change should be clear. I'm not going to bring you a broomstick to prove it.

from sbupdate.

See https://0pointer.net/blog/brave-new-trusted-boot-world.html, section "Revocation/Rollback Protection" which talks about how this could be handled.

from sbupdate.