4 ms·
Ubuntu's Server Installer Leaked Encrypted Storage Passphrase to Its Log
- nemetroid 6y agoI believe this commit is the fix: https://github.com/CanonicalLtd/subiquity/commit/7db70650feaf513d7fb6f1ca07f2d670a0890613 https://github.com/CanonicalLtd/subiquity/commit/7db70650fea... I was a little surprised by how it did so just by adding a function, so I looked briefly into how the serialization seems to work. The FileSystemModel holds a numbers of actions, which it renders[0] into a config for the Curtin program. Part of this process consists of converting instances of various classes into dicts[1] (which presumably become JSON later on). This config is written to various files in /var/log/installer/ during setup. The conversion into dicts is highly dynamic: it looks up all the fields of the object to be converted, and for each field looks for a "serialize_<field_name>" function on the object. If such a function is present, it is used to serialize the field. If not, the field is typically serialized using its literal value. One such action class is DM_Crypt[2], which has a "key" field containing the secret. With this commit, the serialize_key() function will be used to write the key itself into a temporary file, and only store the location of the file into the config. 0: https://github.com/CanonicalLtd/subiquity/blob/7db70650feaf513d7fb6f1ca07f2d670a0890613/subiquity/models/filesystem.py#L1563 https://github.com/CanonicalLtd/subiquity/blob/7db70650feaf5... 1: https://github.com/CanonicalLtd/subiquity/blob/7db70650feaf513d7fb6f1ca07f2d670a0890613/subiquity/models/filesystem.py#L376 https://github.com/CanonicalLtd/subiquity/blob/7db70650feaf5... 2: https://github.com/CanonicalLtd/subiquity/blob/7db70650feaf513d7fb6f1ca07f2d670a0890613/subiquity/models/filesystem.py#L1179 https://github.com/CanonicalLtd/subiquity/blob/7db70650feaf5...
- rmrfstar 6y agoI'm not a crypto nerd or an os dev. Is it ever ok to let the key leave ram unencrypted? serialize_key() seems like a recipe for doom.