logged luks passwords

Bug #1878115 reported by Seth Arnold
286
This bug affects 4 people
Affects Status Importance Assigned to Milestone
curtin (Ubuntu)
Invalid
Undecided
Unassigned
subiquity (Ubuntu)
Fix Released
Critical
Unassigned

Bug Description

Fix published in
latest amd64 stable 20.05.2 1874 -
         arm64 stable 20.05.2 1875 -
         ppc64el stable 20.05.2 1876 -
         s390x stable 20.05.2 1873 -

Images respin pending

--

The server installer, perhaps other installers, will log LUKS passwords used on the system via:

- installer/subiquity-curtin-install.conf

 - {volume: disk-sda, key: ...

- curtin/install.log

get_path_to_storage_volume for volume dm_crypt-0({'volume': 'disk-sda', 'key': ...
        get_path_to_storage_volume for volume dm_crypt-0({'volume': 'disk-sda', 'key': ...

- syslog

May 11 22:27:25 ubuntu-server curtin_log.2310[2592]: merged config: {'sources': {'ubuntu00': 'cp:///media/filesystem'}, 'stages': ['early', 'partitioning', 'extract', 'curthooks', 'hook', 'late'], 'extract_commands': {'builtin': ['curtin', 'extract']}, 'hook_commands': {'builtin': ['curtin', 'hook']}, 'partitioning_commands': {'builtin': ['curtin', 'block-meta', 'simple']}, 'curthooks_commands': {'builtin': ['curtin', 'curthooks'], '000-configure-run': ['/snap/bin/subiquity.subiquity-configure-run'], '001-configure-apt': ['/snap/bin/subiquity.subiquity-configure-apt', '/snap/subiquity/1866/usr/bin/python3', 'true']}, 'late_commands': {'builtin': []}, 'network_commands': {'builtin': ['curtin', 'net-meta', 'auto']}, 'apply_net_commands': {'builtin': []}, 'install': {'log_file': '/var/log/curtin/install.log', 'error_tarfile': '/var/log/curtin/curtin-error-logs.tar', 'save_install_config': '/var/log/installer/curtin-install-cfg.yaml', 'save_install_log': '/var/log/installer/curtin-install.log', 'target': '/target', 'unmount': 'disabled'}, 'apt': {'preserve_sources_list': False, 'primary': [{'arches': ['amd64', 'i386'], 'uri': 'http://se.archive.ubuntu.com/ubuntu'}, {'arches': ['default'], 'uri': 'http://ports.ubuntu.com/ubuntu-ports'}]}, 'debconf_selections': {'subiquity': ''}, 'grub': {'probe_additional_os': True, 'terminal': 'unmodified'}, 'kernel': {'package': 'linux-generic'}, 'pollinate': {'user_agent': {'subiquity': '20.05.1_1866'}}, 'reporting': {'subiquity': {'identifier': 'curtin_event.2310', 'type': 'journald'}}, 'storage': {'config': [{'ptable': 'gpt', 'serial': 'XXX', 'wwn': 'XXX', 'path': '/dev/nvme0n1', 'wipe': 'superblock', 'preserve': False, 'name': '', 'grub_device': False, 'type': 'disk', 'id': 'disk-nvme0n1'}, {'serial': 'XXX', 'wwn': 'XXX', 'path': '/dev/sda', 'wipe': 'superblock', 'preserve': False, 'name': '', 'grub_device': False, 'type': 'disk', 'id': 'disk-sda'}, {'device': 'disk-nvme0n1', 'size': 536870912, 'wipe': 'superblock', 'flag': 'boot', 'number': 1, 'preserve': False, 'grub_device': True, 'type': 'partition', 'id': 'partition-0'}, {'fstype': 'fat32', 'volume': 'partition-0', 'preserve': False, 'type': 'format', 'id': 'format-0'}, {'device': 'disk-nvme0n1', 'size': 127496355840, 'wipe': 'superblock', 'flag': '', 'number': 2, 'preserve': False, 'type': 'partition', 'id': 'partition-1'}, {'fstype': 'btrfs', 'volume': 'partition-1', 'preserve': False, 'type': 'format', 'id': 'format-1'}, {'device': 'format-1', 'path': '/', 'type': 'mount', 'id': 'mount-1'}, {'volume': 'disk-sda', 'key': ...

We shouldn't be logging this passphrase to disk, even inside the encrypted portion, because it's too easy for the password to leak, as it has here.

Thanks

CVE References

information type: Private Security → Public Security
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in curtin (Ubuntu):
status: New → Confirmed
Changed in subiquity (Ubuntu):
status: New → Confirmed
Revision history for this message
Paul Gear (paulgear) wrote :

I've confirmed on a 20.04 system recently installed from the official server ISO that the passphrase for the newly-created LUKS volume appears in the following files in /var/log/installer after install:

autoinstall-user-data curtin-install-cfg.yaml curtin-install.log installer-journal.txt subiquity-curtin-install.conf

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

I intend to fix this by passing the passphrase via a temporary file in /run/subiquity instead of in the curtin config.

Changed in subiquity (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Critical
Revision history for this message
Alex Murray (alexmurray) wrote :

CVE-2020-11932 has been assigned for this issue.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

curtin already accepts either plaintext or a keyfile, so only changes in subiquity needed to start using keyfile.

Changed in curtin (Ubuntu):
status: Confirmed → Invalid
description: updated
Changed in subiquity (Ubuntu):
status: Triaged → Fix Committed
Changed in subiquity (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Geert-Johan Riemer (geertjohan) wrote :

What would be the proper way to remove these logs when they contain a pasword? `shred /var/log/installer && rm -rf /var/log/installer`?

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

@geertjohan => that sounds good enough. Or you might want to back up /var/log/installer and encrypt it.

Revision history for this message
Benjamin Schmid (benbuntu) wrote :

@geertjohan: Many modern filesystems are using a journal, so way more reasonable seems to take the password as compromised and change it: Changing LUKS passphrase can be achieved interactively via gnome-disks or manually via commandline:

   cryptsetup luksChangeKey <target device> -S <target key slot number: 0..7>

Revision history for this message
Zbigniew Jędrzejewski-Szmek (zbyszek-in) wrote :

Oh, man. Once the password is written to a file on a real disk (/var/...), it should be considered compromised. Using shred or rm makes no guarantee that the bytes are removed from the device. In particular, it would be fairly trivial to do something like "grep 'merged config' /dev/sda" and chances are that this will find the password if it was written there.

Writing the password to /run/... is much much better though not ideal. /run is backed by a tmpfs, and tmpfs contents can be written out to swap. Chances of this happening and password being retrievable from disk are much smaller than in case of a disk-backed filesystem, but keeping the password always in mlocked memory would be better.

Revision history for this message
Christian Sarrasin (sxc731) wrote :

Just to clarify, is it correct that this issue only affects systems initially deployed with 20.04? On my 19.10 upgraded system, `grep -r` didn't reveal anything suspicious. I'm sorry if this is obvious from the launchpad metadata (it's not to me)

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote : Re: [Bug 1878115] Re: logged luks passwords

On Fri, 15 May 2020 at 20:01, Zbigniew Jędrzejewski-Szmek <email address hidden>
wrote:

> Oh, man. Once the password is written to a file on a real disk
> (/var/...), it should be considered compromised. Using shred or rm makes
> no guarantee that the bytes are removed from the device. In particular,
> it would be fairly trivial to do something like "grep 'merged config'
> /dev/sda" and chances are that this will find the password if it was
> written there.
>

I agree with this.

> Writing the password to /run/... is much much better though not ideal.
> /run is backed by a tmpfs, and tmpfs contents can be written out to
> swap. Chances of this happening and password being retrievable from disk

are much smaller than in case of a disk-backed filesystem, but keeping
> the password always in mlocked memory would be better.
>

The server installer does not set up swap and the filesystem is a
tmpfs-backed overlay so that risk doesn't really apply here.

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

On Fri, 15 May 2020 at 21:32, Christian Sarrasin <email address hidden>
wrote:

> Just to clarify, is it correct that this issue only affects systems
> initially deployed with 20.04? On my 19.10 upgraded system, `grep -r`
> didn't reveal anything suspicious. I'm sorry if this is obvious from
> the launchpad metadata (it's not to me)
>

No, this has been around a while I'm afraid.

Revision history for this message
Tom Reynolds (tomreyn) wrote :

Thanks for the fast fix of Subiquity. Personally, I continue to consider Ubuntu installers to be affected. To me, the ability to live upgrade Subiquity (where Internet access is available) is a nice workaround.

Could we clarify which Ubuntu releases (or their installers) are (not) affected in that they come with a version of Subiquity pre-installed which is subject to this bug?

The first post states "Images respin pending" - will there be new ISOs?

Thanks.

To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.