| 4 Jul 2024 |
 hexa | * https://github.com/NixOS/nixpkgs/pull/324587 merged into release-24.05, nixos-24.05-small eval triggered | 15:59:31 |
|  Kerstin (she/her) joined the room. | 16:01:33 |
|  Benedikt changed their display name from Soispha to Benedikt. | 19:10:30 |
| 5 Jul 2024 |
 Septem9er | Hey,
it seems like there is an regression of CVE-2023-36476 in the Nixos-calamares-extension, aka. the graphical NixOS-Installer.
The commit fixing this was reverted for some reason. It seems like they wanted to fix it another way in this commit. I haven't really looked into what they try to do in this commit, however the commit message was the following:
Do not use crypto_keyfile.bin in UEFI, but leave BIOS the same.
Which doesn't really make sense to me, because the original CVE applied to BIOS systems mostly. So leaving BIOS systems the same wouldn't fix the issue.
Someone reported this here, I could reproduce this with the latest Nixos-GNOME ISO, with the following steps:
- Start the ISO on a BIOS (legacy) system / in BIOS mode
- Select manual partitioning in the installer
- Create an unencrypted legacy-boot partition with mountpoint /boot
- Create an encrypted root partition with mountpoint /
After the installation is done, there is an luks-keyfile in an zstd/cpio archive in /boot/kernels/***-secrets, which does open the root partition.
| 11:36:34 |
 emily | thank you for the report | 11:48:34 |
| emily | https://github.com/NixOS/calamares-nixos-extensions/pull/25 says "#21 broke encrypted swap by mishandling the removal of crypto_keyfile.bin. This reverts the original fix. Instead, we leave BIOS the same; that was secure as it was before", I guess this was just a misunderstanding of the vuln? :/ | 11:49:21 |
| emily | maybe it's better to revert and let encrypted swap be broken while we figure out what the proper fix is? | 11:50:59 |
| emily | (I guess this is going to require another GHSA? it's the month of security regressions…) | 11:51:25 |
| emily | not an expert in this area though so I'll defer to those who are | 11:51:32 |
| hexa | pinged elvishjerrico in #dev:nixos.org | 11:54:40 |
 raitobezarius | i'm confused by the reports | 11:57:01 |
| raitobezarius | it took me time to reload the context | 11:57:05 |
| raitobezarius | but BIOS GRUB users are protected by cryptodisk | 11:57:13 |
| Septem9er | In reply to @emilazy:matrix.org
https://github.com/NixOS/calamares-nixos-extensions/pull/25 says "#21 broke encrypted swap by mishandling the removal of crypto_keyfile.bin. This reverts the original fix. Instead, we leave BIOS the same; that was secure as it was before", I guess this was just a misunderstanding of the vuln? :/ Thanks, I didn't look at the pull request yet.
They also write:
NOTE: This is likely not a completely sufficient solution for users who choose manual partitioning. Mainly, if they create an unencrypted root partition with BIOS boot, it will still insecurely use crypto_keyfile.bin for other partitions that are encrypted.
Since they are specifically writing about unencrypted root partitions only, it seems like they thought it wouldn't be an issue for an encrypted root partiton?
Anyway, I guess this was a misunderstanding about the vulnerability. BIOS setups were definitly affected, the GHSA did specifically say it affects "non-UEFI systems".
| 11:57:52 |
| emily | In reply to @raitobezarius:matrix.org
but BIOS GRUB users are protected by cryptodisk the advisory says
Users who installed NixOS through the graphical calamares installer, with an unencrypted /boot, on either:
| 11:58:16 |
| emily | I guess the key there is "unencrypted /boot"? | 11:58:22 |
| Septem9er | In reply to @raitobezarius:matrix.org
but BIOS GRUB users are protected by cryptodisk Could you elaborate on that? | 11:58:27 |
| emily | UEFI ~always has unencrypted /boot, but on BIOS the happy path is for it to be encrypted? | 11:58:36 |
| raitobezarius | ok the key is indeed forcing to create an unencrypted /boot | 11:58:40 |
| raitobezarius | this should be an invalid configuration | 11:58:51 |
| raitobezarius | without manual partitioning, you cannot reach that state, right? | 11:59:08 |
| raitobezarius | so not sure if it's vuln or (big big) footgun | 11:59:22 |
| emily | the manual partitioning caveats are pretty scary if users have managed to independently construct an insecure configuration in the wild :( | 11:59:41 |
| raitobezarius | In reply to @septem9er:fairydust.space
Could you elaborate on that? well /boot is a cryptodisk in that situation so the keys over there are still as protected as before | 11:59:49 |
| raitobezarius | original reporter says | 12:00:27 |
| raitobezarius |
I have a similar setup with an unencrypted /boot and an encrypted /. When I start the OS it just boots all the way to user login not requiring my decryption password at any time.
| 12:00:28 |
| raitobezarius | but makes no mention of BIOs or UEFI | 12:00:37 |
| raitobezarius | * but makes no mention of BIOS or UEFI | 12:00:41 |
| Septem9er | In reply to @raitobezarius:matrix.org
well /boot is a cryptodisk in that situation so the keys over there are still as protected as before Yeah. The key is an unencryped boot partition, like it was already said. | 12:00:48 |
| raitobezarius | In reply to @septem9er:fairydust.space
Yeah. The key is an unencryped boot partition, like it was already said. yeah but let's distinguish two things | 12:01:04 |
