New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
journalctl: verify that old entries are not sealed with too recent key #28885
Conversation
When verifying seals produced with forward secure sealing, the verification currently does not check that old entries are only sealed with the key for their epoch and not a more recent one. This missing check allows an attacker to remove seals, and create new ones with the currently available key, and verify will claim everything is in order, although all entries could have been modified. This resolves CVE-2023-31439.
3762718
to
540e35e
Compare
Hi there, can someone find the time to review this? I still consider log sealing a security feature and consequently this issue a security vulnerability. |
Thank you for the review, I incorporated all suggestions. Regarding |
Next time, please squash commits, rather than appending commits to address comments. |
systemd#28885) When verifying seals produced with forward secure sealing, the verification currently does not check that old entries are only sealed with the key for their epoch and not a more recent one. This missing check allows an attacker to remove seals, and create new ones with the currently available key, and verify will claim everything is in order, although all entries could have been modified. This resolves CVE-2023-31439. Co-authored-by: Felix Dörre <felix.doerre@kit.edu> (cherry picked from commit 3846d3a)
systemd#28885) When verifying seals produced with forward secure sealing, the verification currently does not check that old entries are only sealed with the key for their epoch and not a more recent one. This missing check allows an attacker to remove seals, and create new ones with the currently available key, and verify will claim everything is in order, although all entries could have been modified. This resolves CVE-2023-31439. Co-authored-by: Felix Dörre <felix.doerre@kit.edu> (cherry picked from commit 3846d3a) (cherry picked from commit ea67d47) (cherry picked from commit e140c1d)
systemd#28885) When verifying seals produced with forward secure sealing, the verification currently does not check that old entries are only sealed with the key for their epoch and not a more recent one. This missing check allows an attacker to remove seals, and create new ones with the currently available key, and verify will claim everything is in order, although all entries could have been modified. This resolves CVE-2023-31439. Co-authored-by: Felix Dörre <felix.doerre@kit.edu> (cherry picked from commit 3846d3a) (cherry picked from commit ea67d47)
When verifying seals produced with forward secure sealing, the verification currently does not check that old entries are only sealed with the key for their epoch and not a more recent one. This missing check allows an attacker to remove seals, and create new ones with the currently available key, and verify will claim everything is in order, although all entries could have been modified. This PR adds the missing check. A proof-of-concept implementation to break and re-seal a journal is available here: https://github.com/kastel-security/Journald. With this patch applied the attack does not succeed anymore.
This change should be compatible as it only adjusts verification, so old (untampered) journals can be verified with the new
journalctl
, and "new" journals are identical and can be verified with the oldjournalctl
.This resolves CVE-2023-31439. See https://github.com/kastel-security/Journald/blob/main/journald-publication.pdf for more background.
See also #28433