Bugzilla – Bug 986971
VUL-0: CVE-2016-5746: libstorage,yast2-storage:: encryption passphrases written to temporary files on disk
Last modified: 2018-10-04 14:42:43 UTC
libstorage stores passphrases for encrypted partitions/volumes in a temporary file on disk. This is not an issue in a distribution installer situation, where tmpdir of the installer is not on permanent storage. However in an installed system, managing (opening, creating) any encrypted storage with libstorage / YaST2 writes the clear passphrases to disks. This exposes current, past or even mistyped or unused passphrases for encrypted storage devices on permanent storage, as remnants of unlinked temporary files. In the case of a crash or termination of the process using libstorage, this is even kept as a file. The attack vector is someone gaining access to the raw storage at any later point even if the encrypted storage is no longer mounted or present, either through privilege escalation or physical access. /tmp/libstorage-XXXXXX is actually created with mode 700. /tmp/libstorage-XXXXXX/pwdf is created with mode 611. Mitigating factors: * full disk encryption or partial encryption covering /tmp * /tmp on tempfs (modulo cold boot attack vectors) Code locations: The path used is getStorage()->tmpDir() + "/pwdf" The parent is created in Storage::initialize() e.g. /tmp/libstorage-XXXXXX The passphrase for opening volumes and creating volumes is written to a temporary file in: storage::Volums::detectEncyption() storage::Volume::doCryptsetup(bool readonly) storage::Volume::doLosetup() It is passed to storage::Volume::getCryptsetupCmd() where a cryptsetup command is constructed in which the pwdf file is used as a keyfile. The command is executed by callers of getCryptsetupCmd() The temporary file is overwritten for subsequent The temporary is not removed until the destrucor Storage::~Storage() is called. Consideration: cryptsetup {luksOpen,luksFormat} (and the dm equivalents used elsewhere) have the option to read key material from stdin, which should be preferred over the solution described.
bugbot adjusting priority
CWE-313: Cleartext Storage in a File or on Disk Assigning CVE-2016-5746 Rating CVSS v2 4.7 (AV:L/AC:H/Au:N/C:C/I:P/A:N)
Making public. Note that a past exposure of key material (dm: key; LUKS: key slot passphrase) is not addressed by a code fix or maintenance update alone. Corrective action may also also include, e.g. for LUKS: * re-encrypt the affected storage if required. Note that this is different from changing the passphrase. This is due the structure of the LUKS header with one or more passphrases protecting the single master key. * consider any LUKS header back-ups corresponding to a key slot passphrase used previously * changing passphrases re-used elsewhere Mitigating factors: * full disk encryption or partial encryption covering /tmp * /tmp on tmpfs (modulo cold boot attack vectors)
Patch against SLE-12 SP2: https://github.com/openSUSE/libstorage/pull/161
Test procedure 1: Crypto file in installed system ================================================= - Build and install libstorage with the above patch. - Start YaST expert partitioner with that libstorage; create a crypto file there: - In the "System View" tree on the left, select "Crypt Files" - Click "Add Crypt File" button - Enter "/tmp/crypto-01" in the "Path Name of Loop File" field - Check "Create Loop File" - Click "Next" button - Enter "/crypto-01" in the "Mount Point" field - Click "Next" button - Enter a password in the next dialog - Enter the same password again in the second password field - Click "Next" button -> The "Crypt Files" table should now have an entry like this: /dev/mapper/cr_crypto-01 50.00 MiB XFS /crypto-01 * - Click "Next" button to see the changes summary - Click "Finish" button to execute the changes -> There should now be a new crypted file system mounted on /crypto-01 mount | grep crypt /dev/mapper/cr_crypto-01 on /crypto-01 type xfs ... cat /etc/crypttab cr_crypto-01 /tmp/crypto-01 none none ls -l /dev/mapper total 0 crw------- 1 root root 10, 236 Jul 6 14:22 control lrwxrwxrwx 1 root root 7 Jul 13 16:39 cr_crypto-01 -> ../dm-0 - Create one or more test files on the new crypted file system: cd /crypto-01 echo "echo "Kilroy was here" >test.txt - Unmount and close the crypto file: umount /crypto-01 cryptsetup luksClose cr_crypto-01 ls -l /dev/mapper total 0 crw------- 1 root root 10, 236 Jul 6 14:22 control sudo dmsetup table No devices found - Open and mount it manually: cryptsetup luksOpen /tmp/crypto-01 cr_crypto-01 Enter passphrase for /tmp/crypto-01: ... mount /dev/mapper/cr_crypto-01 /crypto-01 - Check contents: ls -l /crypto-01 total 4 -rw-r--r-- 1 root root 16 Jul 13 16:44 test.txt cat /crypto-01/test.txt Kilroy was here - Clean up: Close and unmount again umount /crypto-01 cryptsetup luksClose cr_crypto-01 - Remove the entry from /etc/crypttab (or delete that file if that was the only entry) - Remove mount point rmdir /crypto-01 - Remove entry from /etc/fstab
Creating an ISO with the patched libstorage for the target code stream ====================================================================== - Build RPMs with the patched libstorage for the target code stream - Create a driver update disk (DUD) with those RPMs: cd ~/space/rpms rm -f *.rpm osc -A ibs getbinaries -d . home:shundhammer:storage libstorage \ SLE_12_SP1 x86_64 libstorage-devel-2.26.4-2.1.x86_64.rpm 100% libstorage-python-2.26.4-2.1.x86_64.rpm 100% libstorage-ruby-2.26.4-2.1.x86_64.rpm 100% libstorage-testsuite-2.26.4-2.1.x86_64.rpm 100% libstorage7-2.26.4-2.1.x86_64.rpm 100% rm libstorage-testsuite*.rpm mkdud -c ../iso/pipe-pw.dud --dist sles12 --obs-keys libstorage*.rpm - Integrate that DUD into the installation DVD: mksusecd --create SLE-12-SP2-patched-DVD1.iso --initrd \ pipe-pw.dud \ SLE-12-SP2-Server-DVD-x86_64-Beta4-DVD1.iso
Test procedure 2: Installation with crypted LVM =============================================== This tests if the new password handling is compatible to the old one: - Start an installation (QEMU or VirtualBox) with the original (unpatched!) ISO - Change the partitioning proposal to "encrypted LVM". Make sure to write down or memorize the encryption password. - Perform the installation - During reboot at the end of the installation, check if the encryption password works to unlock the partitions (log in to that new installation to check) - Shut down that newly installed system - Start an installation on the same (virtual) disk with the patched ISO - The installer should detect that there is an encrypted LVM and ask for the password - Enter the password and check if there were any complaints. - At the storage proposal, again select "encrypted LVM" (the password will remain the same; you will not be prompted again) - Perform the installation - During reboot at the end of the installation, check if the encryption password works to unlock the partitions (log in to that new installation to check)
Successfully tested test procedure 1 and 2 on Git master (Factory/SLE-12 SP2).
Backport to libstorage-ng: https://github.com/openSUSE/libstorage-ng/pull/123 (SystemCmd + unit test only since no crypto support yet)
This fix will appear in SLE-12 SP2 as libstorage7-2.26.4 .
Backport to SLE-12 SP1: https://github.com/openSUSE/libstorage/pull/162
Backport to SLE-12 GA: https://github.com/openSUSE/libstorage/pull/163
An update workflow for this issue was started. This issue was rated as moderate. Please submit fixed packages until 2016-08-11. When done, reassign the bug to security-team@suse.de. https://swamp.suse.de/webswamp/wf/62916
Backport to SLE-12 SP1 is merged: https://github.com/openSUSE/libstorage/pull/162
Backport to SLE-12 GA is merged: https://github.com/openSUSE/libstorage/pull/163
Successfully performed test procedure #2 with SLE-12 SP1.
Submit request against SUSE_SLE-12-SP1_Update: https://build.suse.de/request/show/119676 Submit request against SUSE_SLE-12_Update: https://build.suse.de/request/show/119669
Backport to SLE-11 SP4: https://github.com/yast/yast-storage/pull/223 (Notice that prior to SLE-12, libstorage was part of the yast2-storage package)
Backport to SLE-11 SP3: https://github.com/yast/yast-storage/pull/224
Submit request against SUSE_SLE-11-SP4_Update: https://build.suse.de/request/show/119861 Submit request against SUSE_SLE-11-SP3_Update: https://build.suse.de/request/show/119862
SUSE-SU-2016:2189-1: An update that fixes one vulnerability is now available. Category: security (moderate) Bug References: 986971 CVE References: CVE-2016-5746 Sources used: SUSE Linux Enterprise Software Development Kit 12-SP1 (src): libstorage-2.25.35.1-3.1 SUSE Linux Enterprise Server 12-SP1 (src): libstorage-2.25.35.1-3.1 SUSE Linux Enterprise Desktop 12-SP1 (src): libstorage-2.25.35.1-3.1
Backport to SLE-11 SP1: https://github.com/yast/yast-storage/pull/226 I created RPMs in the IBS with that version, built a DUD, integrated that DUD into the SLES-11-SP1 ISO and tested with that ISO: It installs without problem, and the created encrypted LVM can successfully be decrypted so that system boots without any problems.
Submit request against SUSE_SLE-11-SP1_Update: https://build.suse.de/request/show/120419
Backport to SLE-10 SP3: https://github.com/yast/yast-storage/pull/227 Notice that SLE-10 SP3 does not support creating encrypted LVM volumes. Test with test procedure #1 from comment #8 instead.
New submit request against SLE-11 SP1 after the yast2-devtools had broken the .spec file and the previous SR was rejected: https://build.suse.de/request/show/120467
Submit request against SUSE_SLE-10-SP3_Update_Test: https://build.suse.de/request/show/120470
New submit request against SUSE_SLE-10-SP3_Update_Test: https://build.suse.de/request/show/120765
openSUSE-SU-2016:2264-1: An update that fixes one vulnerability is now available. Category: security (moderate) Bug References: 986971 CVE References: CVE-2016-5746 Sources used: openSUSE Leap 42.1 (src): libstorage-2.25.35.1-6.1, yast2-storage-3.1.71-4.1
I was just made aware that the test procedure from comment #8 doesn't work for SLES-11 and older: You have to call "losetup" manually to set up and break down the devices, and you have to use the loop devices at certain points: SLES-11-SP4 # ls -lh /tmp/cr* -rw-r--r-- 1 root root 50M Sep 20 12:10 /tmp/crypto-01 SLES-11-SP4 # losetup -a # check what loop devices are in use SLES-11-SP4 # losetup -f # check the next free loop device /dev/loop0 SLES-11-SP4 # losetup /dev/loop0 /tmp/crypto-01 SLES-11-SP4 # cryptsetup luksOpen /dev/loop0 cr_crypto-01 Enter passphrase for /dev/loop0: .... SLES-11-SP4 # ls -l /dev/mapper total 0 crw-rw---- 1 root root 10, 236 Sep 20 11:08 control lrwxrwxrwx 1 root root 7 Sep 20 12:16 cr_crypto-01 -> ../dm-0 SLES-11-SP4 # mount /dev/mapper/cr_crypto-01 /crypto-01 SLES-11-SP4 # ls -l /crypto-01 total 13 drwx------ 2 root root 12288 Sep 20 11:50 lost+found -rw-r--r-- 1 root root 16 Sep 20 11:51 test.txt # Clean up SLES-11-SP4 # umount /crypto-01 SLES-11-SP4 # losetup -a /dev/loop0: [fd02]:1908757 (/tmp/crypto-01) SLES-11-SP4 # cryptsetup luksClose cr_crypto-01 SLES-11-SP4 # losetup -a /dev/loop0: [fd02]:1908757 (/tmp/crypto-01) SLES-11-SP4 # losetup -d /dev/loop0 # shut down loop device SLES-11-SP4 # losetup -a # check if anything is left now SLES-11-SP4 # ls -l /dev/mapper # check if the mapped device is gone total 0 crw-rw---- 1 root root 10, 236 Sep 20 11:08 control SLES-11-SP4 #
SUSE-SU-2016:2353-1: An update that solves one vulnerability and has three fixes is now available. Category: security (moderate) Bug References: 937942,984245,986971,996208 CVE References: CVE-2016-5746 Sources used: SUSE Linux Enterprise Software Development Kit 11-SP4 (src): yast2-storage-2.17.161-5.1 SUSE Linux Enterprise Server 11-SP4 (src): yast2-storage-2.17.161-5.1 SUSE Linux Enterprise Debuginfo 11-SP4 (src): yast2-storage-2.17.161-5.1
SUSE-SU-2016:2355-1: An update that fixes one vulnerability is now available. Category: security (moderate) Bug References: 986971 CVE References: CVE-2016-5746 Sources used: SUSE Linux Enterprise Server for SAP 12 (src): libstorage-2.25.16.1-3.1 SUSE Linux Enterprise Server 12-LTSS (src): libstorage-2.25.16.1-3.1
Fixed for all requested releases now.