logged luks passwords

[Seth Arnold]

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

[Launchpad Janitor (janitor)]

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

[Paul Gear (paulgear)]

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

[Michael Hudson-Doyle (mwhudson)]

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

[Alex Murray (alexmurray)]

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

[Dimitri John Ledkov (xnox)]

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

[Geert-Johan Riemer (geertjohan)]

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

[Dimitri John Ledkov (xnox)]

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

[Benjamin Schmid (benbuntu)]

@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>

[Zbigniew Jędrzejewski-Szmek (zbyszek-in)]

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.

[Christian Sarrasin (sxc731)]

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)

[Michael Hudson-Doyle (mwhudson)]

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.

[Michael Hudson-Doyle (mwhudson)]

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.

[Tom Reynolds (tomreyn)]

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.