25
Does that happen often? I had, apparently incorrectly, assumed those things were more or less fire and forget.
Bootloaders are also software affected by vulnerabilities (CVE's). But this comment did make me curious. Do the CVE's that affect grub, would a person of threat model/usecase 1 in my comment above care about them?
Many of them do indeed seem to non issues. From the list here.
Grub CVE's requiring the config file to be malicious, like this one are pretty much non issues. The config file is encrypted, in my setup at least (but again, not the default. Also idk if the config file is signed/verified).
I think this one is somewhat concerning. USB devices plugged in could corrupt grub.
Someone could possibly do something similar with hard drives, replacing the one in the system. The big theoretical vulnerability I am worried about is someone crafting a partition in such a way that it does RCE through Grub. Or maybe's it's already happened, my research isn't that deep. But with such a vulnerability, someone could shrink the EFI partition and then put another partition there, that grub reads, and then the code execution exploit happens.
But honestly, if someone could replace/modify hard drives, or add/remove USB devices, what if they just replace your entire system motherboard with a malicious one? This is very difficult to defend against, but you could check for it happening by having your motherboard be password protected, and you always log into your motherboard whenever you boot to make sure the password is the same. (Although perhaps someone could copy over the hashes (at least I am assuming the passwords are hashed) from one motherboard to another).
But if something like that is in your threat model, it's important to note that ethernet, and many other firmware is proprietary (meaning you cannot audit or modify the code), and also has what's called "DMA" — direct memory access. It can read and write to the Linux kernel with permissions higher than root. So if I have access to your device, I could replace your wifi card with a malicious one that modifies stuff after you boot or does any other things.
What you are supposed to do is prevent tampering in the first place, or for a much cheaper cost, have "tamper evident protection", things that inform you if the system was tampered with. Stickers over the screws are an easy and cheap example..
But DefCon has a village dedicated to breaking tamper evident protection. Lol.
I think if your adversary is a nationstate, secure boot usecase 1 is simply broken and doesn't work. It's too easy to replace any of the physical components with malicious one's for them, because there is no verification of those. I think Secure Boot usecase 1 is for protecting against corporate espionage in mid to high tier corpos. Corporations also tend to give people devices, and they can ensure that those devices have tamper evidence/tamper resistance on top of secure boot. Of course I think a nationstate can get through them, but I don't think it's included in the threat model.
Nationstates can easily break the system of secure boot, and probably have methods in addition to or separate from secure boot for protecting themselves.
Wait what, that just seems like home directory encryption with extra steps 🤦 I guess I’ll go back to Veracrypt then.
Performance on LUKS might be better since LUKS is a first class citizen. But maybe performance with veracrypt is better since only the home directory is encrypted. I tried duckduckgo but the top results were AI slop with no benchmarks so I'm not gonna bother doing further research.
Many helm charts, like authentik or forgejo integrate bitnami helmcharts for their databases. So that's why this is concerning to me,
But, I was planning to switch to operators like cloudnativepostgres for my databases instead and disable the builtin bitnami images. When using the builtin bitnami images, automatic migration between major releases is not supported, you have to do it yourself manually and that dissapointed me.