Calamares Initramfs Weakness
Jul 6, 2019
Systems installed by Calamares up to and including Calamares 3.2.10 may leak cryptographic keys via lax file permissions on initramfs files. This may allow unprivileged users to obtain the decryption keys for encrypted disks.
In addition, during installation by Calamares up to and including Calamares 3.2.10 there is a window of opportunity for reading cryptographic keys via lax file permissions. This may allow unprivileged users to obtain the decryption keys for encrypted disks.
It has been almost exactly two years since the last CVE for Calamares. This time, there are two ways to leak the cryptographic keys used to encrypt disks using LUKS.
umask
Under POSIX, a file’s permissions are given by three groups of file permission bits; the groups give permissions for the owner, group and other users of the systems. A file which gives read-permission to others is, of course, readable by everyone on the system.
Under POSIX, a process has a so-called umask, which are bits that are switched off when creating a file. In particular, a umask value of 077 (that is octal, so it is three zero bits, followed by six one bits) switches off group and other permissions, so creating a file with that umask set will yield a file that is not readable by others. A umask of 077 is “safe”.
For more explanation of file permissions bits, please see the Debian wiki on permissions.
Key File Permissions
( CVE-2019-13178 #1190 )
A key file for LUKS encryption is generated by Calamares. This key file is sensitive information, because it is used to encrypt the hard disk where the installation takes place, and an attacker with access to the key file can use that to defeat disk encryption.
The generation of the key file in Calamares versions up to 3.2.10 is as follows:
- generate the key file,
chmodthe key file to 0600 (readable by user/owner only).
When the file is generated, there is a window of opportunity between
generation and chmod to read the file, if the file is generated
with lax permissions.
To exploit this, an attacker must be logged in to the machine that is being installed, during installation, and the file must be generated with lax permissions. Most Live CDs seem to use an unsafe umask of 022, allowing the file to be created with permissions 0644. In the brief instant that the file exists but has not had the permissions changed to 0600, it could be read by an attacker.
Calamares now explicitly sets the umask to a safe value before creating the key file. (An additional mitigation, creating the file with explicit permissions 0600 instead of relying on umask, will be added in a later Calamares release).
Distributions are encouraged, in addition, to set a safe umask for the root user, or to set a safe umask during installation.
Initramfs Information Leak
( CVE-2019-13179 #1191 )
Most Linux systems boot using an initial ramfs, containing tools, drivers, and data used during system boot. For an encrypted hard disk, that data includes the key file that is used to encrypt the hard disk. The initial ramfs is generally stored on an encrypted boot partition, but it is a regular file once the system has booted. If an attacker can read the initial ramfs file, the attacker can extract the key file from the initial ramfs – it is not otherwise encrypted on-disk.
After installation, any user on the installed system may be able
to read the initial ramfs (if it installed with vulnerable permissions),
and extract the key information. Unless something changes the permissions
on the initial ramfs file, this vulnerability persists across reboots
and any user with access to the /boot directory (where initial ramfs files live)
can obtain the key.
The generation of the initial ramfs is done through tools external to Calamares. Depending on the distribution,
- update-initramfs (generally, Debian derivatives)
- mkinitcpio (generally, Arch derivatives)
- dracut (generally, Fedora derivatives) one of these three tools is used.
Users of dracut are not vulnerable, as it has had code in place for CVE-2012-4453 for many years. It sets umask 077 before generating the initial ramfs, and the resulting file is not readable for others.
Users of mkinitcpio may be vulnerable, since it uses the umask when generating new files. Most Live CDs that use mkinitcpio seem to have an unsafe umask of 022 set, so that the resulting file is readable by others. Calamares now sets a safe umask before generating the file, and actively changes the permissions on initial ramfs files to a safe value during installation.
Users of update-initramfs may be vulnerable, since it requires explicit configuration to set a umask. If there is no explicit configuration, the tool uses an unsafe umask value of 022 regardless of the environment’s umask setting. Most installed systems seem to have no explicit setting, and the initial ramfs file is readable by others. Calamares now intrusively adds a configuration snippet that sets a safe umask before creating the initial ramfs.
Mitigations
For installated systems with a potentially vulnerable initial ramfs:
- set a safe umask for the root user,
- change the permissions of initial ramfs files in
/bootto a safe value, - (for users of update-initramfs) add a configuration snippet to set the umask to a safe value when creating initial ramfs files.
Distributions
A new Calamares version, 3.2.11, has been released. It contains code to address both weaknesses: the key file is generated safely. Initial ramfs files are generated with a safe umask and with an additional safe configuration snippet.
The default configuration for Calamares in version 3.2.11 is to use safe settings. It is possible for distributions to disable the safe-settings with an explicit choice in the configuration files – this may be sensible if the distribution has other mitigations (in particular for update-initramfs) in place.
Existing ISO images, of course, contain vulnerable installation code and will continue to do so until new ISO images are released.