|
|
Search Results
There are 11 CVE Records that match your search.
| Name | Description |
|---|---|
| CVE-2024-43378 | calamares-nixos-extensions provides Calamares branding and modules for NixOS, a distribution of GNU/Linux. Users who installed NixOS through the graphical installer who used manual disk partitioning to create a setup where the system was booted via legacy BIOS rather than UEFI; some disk partitions are encrypted; but the partitions containing either `/` or `/boot` are unencrypted; have their LUKS disk encryption key file in plain text either in `/crypto_keyfile.bin`, or in a CPIO archive attached to their NixOS initrd. `nixos-install` is not affected, nor are UEFI installations, nor was the default automatic partitioning configuration on legacy BIOS systems. The problem has been fixed in calamares-nixos-extensions 0.3.17, which was included in NixOS. The current installer images for the NixOS 24.05 and unstable (24.11) channels are unaffected. The fix reached 24.05 at 2024-08-13 20:06:59 UTC, and unstable at 2024-08-15 09:00:20 UTC. Installer images downloaded before those times may be vulnerable. The best solution for affected users is probably to back up their data and do a complete reinstallation. However, the mitigation procedure in GHSA-3rvf-24q2-24ww should work solely for the case where `/` is encrypted but `/boot` is not. If `/` is unencrypted, then the `/crypto_keyfile.bin` file will need to be deleted in addition to the remediation steps in the previous advisory. This issue is a partial regression of CVE-2023-36476 / GHSA-3rvf-24q2-24ww, which was more severe as it applied to the default configuration on BIOS systems. |
| CVE-2023-36476 | calamares-nixos-extensions provides Calamares branding and modules for NixOS, a distribution of GNU/Linux. Users of calamares-nixos-extensions version 0.3.12 and prior who installed NixOS through the graphical calamares installer, with an unencrypted `/boot`, on either non-UEFI systems or with a LUKS partition different from `/` have their LUKS key file in `/boot` as a plaintext CPIO archive attached to their NixOS initrd. A patch is available and anticipated to be part of version 0.3.13 to backport to NixOS 22.11, 23.05, and unstable channels. Expert users who have a copy of their data may, as a workaround, re-encrypt the LUKS partition(s) themselves. |
| CVE-2021-4122 | It was found that a specially crafted LUKS header could trick cryptsetup into disabling encryption during the recovery of the device. An attacker with physical access to the medium, such as a flash disk, could use this flaw to force a user into permanently disabling the encryption layer of that medium. |
| CVE-2020-11932 | It was discovered that the Subiquity installer for Ubuntu Server logged the LUKS full disk encryption password if one was entered. |
| CVE-2019-13179 | Calamares versions 3.1 through 3.2.10 copies a LUKS encryption keyfile from /crypto_keyfile.bin (mode 0600 owned by root) to /boot within a globally readable initramfs image with insecure permissions, which allows this originally protected file to be read by any user, thereby disclosing decryption keys for LUKS containers created with Full Disk Encryption. |
| CVE-2019-13178 | modules/luksbootkeyfile/main.py in Calamares versions 3.1 through 3.2.10 has a race condition between the time when the LUKS encryption keyfile is created and when secure permissions are set. |
| CVE-2017-18191 | An issue was discovered in OpenStack Nova 15.x through 15.1.0 and 16.x through 16.1.1. By detaching and reattaching an encrypted volume, an attacker may access the underlying raw volume and corrupt the LUKS header, resulting in a denial of service attack on the compute host. (The same code error also results in data loss, but that is not a vulnerability because the user loses their own data.) All Nova setups supporting encrypted volumes are affected. |
| CVE-2010-1149 | probers/udisks-dm-export.c in udisks before 1.0.1 exports UDISKS_DM_TARGETS_PARAMS information to udev even for a crypt UDISKS_DM_TARGETS_TYPE, which allows local users to discover encryption keys by (1) running a certain udevadm command or (2) reading a certain file under /dev/.udev/db/. |
| CVE-2009-3279 | The QNAP TS-239 Pro and TS-639 Pro with firmware 2.1.7 0613, 3.1.0 0627, and 3.1.1 0815 create a LUKS partition by using the AES-256 cipher in plain CBC mode, which allows local users to obtain sensitive information via a watermark attack. |
| CVE-2009-3278 | The QNAP TS-239 Pro and TS-639 Pro with firmware 2.1.7 0613, 3.1.0 0627, and 3.1.1 0815 use the rand library function to generate a certain recovery key, which makes it easier for local users to determine this key via a brute-force attack. |
| CVE-2009-3200 | The QNAP TS-239 Pro and TS-639 Pro with firmware 2.1.7 0613, 3.1.0 0627, and 3.1.1 0815 create an undocumented recovery key and store it in the ENCK variable in flash memory, which allows local users to bypass the passphrase requirement and decrypt the hard drive by reading this variable, deobfuscating the key, and running a cryptsetup luksOpen command. |
|
You can also search by reference using the CVE Reference Maps.
For More Information: CVE Request Web Form (select “Other” from dropdown)
|
||
