I don’t really understand. The claim is that there is signature checking for the kernel, but not for the actual kernel that’s loaded, but for some past kernel instead. Is that right but y’all think that the code that’s being run is otherwise protected just fine, or that they’re not understanding what’s being validated, or that the signature validation isn’t about verifying the provenance of kernel code?
iiuc the “bug” report is that object files created by the root user during a kernel build are not verified before those objects are linked into a new kernel.
The objects are owned by root and the programs used to create the objects are owned by root.
In other words, “someone with root access can compromise the system”. You don’t say!
In other words, “someone with root access can compromise the system”. You don’t say!
A lot of UNIX hardening is about trying to prevent someone who gets transient root access from getting persistent root (or, worse, undetectable persistent root) access. If you’re doing secure boot, then the requirement is to compromise both the root account (which can install the new kernel) and whatever owns the signing key so that you can build a malicious kernel to install.
If the security model is standard old fashioned unix users and file permissions, what’s the verification of SHA signature for? Other operating systems check signature on kernels so that a local privilege escalation can’t persist across reboots.
I am not exactly sure I understand the issue here. Is the claim that someone with root access to the file system could add payloads to the kernel that would be linked in on the next reboot? And the workaround is to remove the linker?
And are they also claiming that since each relinked kernel is unique there is no way to check that the new kernel is safe since it will never match a known-good kernel?
I think that they are trying to claim something about auditing. If your kernel was compromised at some point in the past, it’s useful to know when. For OpenBSD, with their relinking thing, an attacker who gains the ability to corrupt a root-owned file (e.g. via a setuid binary that doesn’t sanitise its environment or other state) can inject a rootkit into one of the .o files. Because the kernel binary changes every boot, even logging the hash of the kernel doesn’t easily tell you when this happened.
The problem with their analysis is that you need to have secure boot for this attack to be worthwhile. Without secure boot (which Theo de Raadt has previously been opposed to, so will probably not make it into OpenBSD any time soon), you don’t check kernel signatures in any meaningful way anyway. If you wanted to support secure boot with this randomisation scheme then it’s possible (you would need to sign the kernel with something derived from a PCR that includes the bootloader state and an attestation that the kernel was signed by the same key). The things that the submitter is fixating on (signing .o files) are not very useful to talk about initially because you need an attestation over the whole kernel, which is not necessarily composable from the individual .o files. Ideally you’d have something like a signed immutable filesystem image.
OK, so paraphrasing back to you: basically it’s hard to know when the kernel was compromised, but until secure boot is implemented, the proposed solution is more trouble than it’s worth. It’s a legitimate problem, but the solution is unrealistic.
Not quite. It would be a legitimate attack if not for the fact that there are easier ways for an attacker to achieve the same thing unless you implement secure boot. At that point, this becomes a useful tool for an attacker and you should close this gap.
https://marc.info/?t=168671698400001&r=1&w=2 The thread with Theo.
Checksums are not magic security thingies.
Not sure if the latest instance of “you are already on the other side of the airtight hatchway” is that newsworthy.
Not sure what’s sillier, the “bug” report or the suggested resolution.
Theo is right in sending this person to pasture. Way to waste everybody’s time.
I don’t really understand. The claim is that there is signature checking for the kernel, but not for the actual kernel that’s loaded, but for some past kernel instead. Is that right but y’all think that the code that’s being run is otherwise protected just fine, or that they’re not understanding what’s being validated, or that the signature validation isn’t about verifying the provenance of kernel code?
iiuc the “bug” report is that object files created by the root user during a kernel build are not verified before those objects are linked into a new kernel.
The objects are owned by root and the programs used to create the objects are owned by root.
In other words, “someone with root access can compromise the system”. You don’t say!
A lot of UNIX hardening is about trying to prevent someone who gets transient root access from getting persistent root (or, worse, undetectable persistent root) access. If you’re doing secure boot, then the requirement is to compromise both the root account (which can install the new kernel) and whatever owns the signing key so that you can build a malicious kernel to install.
If the security model is standard old fashioned unix users and file permissions, what’s the verification of SHA signature for? Other operating systems check signature on kernels so that a local privilege escalation can’t persist across reboots.
I am not exactly sure I understand the issue here. Is the claim that someone with root access to the file system could add payloads to the kernel that would be linked in on the next reboot? And the workaround is to remove the linker?
And are they also claiming that since each relinked kernel is unique there is no way to check that the new kernel is safe since it will never match a known-good kernel?
I think that they are trying to claim something about auditing. If your kernel was compromised at some point in the past, it’s useful to know when. For OpenBSD, with their relinking thing, an attacker who gains the ability to corrupt a root-owned file (e.g. via a setuid binary that doesn’t sanitise its environment or other state) can inject a rootkit into one of the .o files. Because the kernel binary changes every boot, even logging the hash of the kernel doesn’t easily tell you when this happened.
The problem with their analysis is that you need to have secure boot for this attack to be worthwhile. Without secure boot (which Theo de Raadt has previously been opposed to, so will probably not make it into OpenBSD any time soon), you don’t check kernel signatures in any meaningful way anyway. If you wanted to support secure boot with this randomisation scheme then it’s possible (you would need to sign the kernel with something derived from a PCR that includes the bootloader state and an attestation that the kernel was signed by the same key). The things that the submitter is fixating on (signing .o files) are not very useful to talk about initially because you need an attestation over the whole kernel, which is not necessarily composable from the individual .o files. Ideally you’d have something like a signed immutable filesystem image.
OK, so paraphrasing back to you: basically it’s hard to know when the kernel was compromised, but until secure boot is implemented, the proposed solution is more trouble than it’s worth. It’s a legitimate problem, but the solution is unrealistic.
Not quite. It would be a legitimate attack if not for the fact that there are easier ways for an attacker to achieve the same thing unless you implement secure boot. At that point, this becomes a useful tool for an attacker and you should close this gap.