New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unsafe generation of initramfs during FDE #1191
Comments
|
This issue has been assigned the CVE ID of CVE-2019-13179 by MITRE. |
|
Hi! according to Mitre all the versions up to 3.2.4 are vulnerable. Kind regards :D |
|
MITRE is wrong, it's all versions up to 3.2.10 and it isn't fixed yet. There's probably a fix for this specific issue in master, though. |
|
@adriaandegroot I'll submit the update to MITRE for both CVEs - the CVEs were submitted with 'discovered in...' - and there was a note attached to it indicating "Not Fixed". That info doesn't get added to the CVE its kept internally. I will ask them to update. |
|
For Ubuntu-derivatives, which use the initramfs module, this should now be fixed. But there are other ways of generating the initramfs (mkinitcpio, for instance), and those have the same problem. So I'm not closing this yet. |
|
Please note, however, that Issue #1190 (CVE-2019-13178) affects all distributions regardless of initramfs generator though. |
|
Since the |
|
I just installed lubuntu (using Calamares) and the initrd was readable by world, even from the more-permissions branch of Calamares, which does more work to keep the initrd readable only by root and sets
So the (re)generation process is ignoring umask anyway. I was going to say "and the cryptfile isn't in there anyway, since |
|
The initramfs is multiple cpio archives, concatenated, so that's why a simple cpio-command won't read them all. The update-initramfs script does not mess with umask. It calls mkinitramfs (in /usr/sbin) which in turn creates an initrd with suffix .new. That file has insecure permissions, and is then moved over top of the existing initrd. This really isn't a Calamares problem at all. |
|
Line 3 of |
|
What Calamares could do (and I guess it must, but really this is a setting that should be applied at the Debian level) is append UMASK=0077 to |
|
(that's |
|
Suggestion from Tom Reyn (mentioned in downstream bug) and from Jonathan Carter and from Alf Gaida and from Kevin Kofler -- so fairly widely supported -- is the following:
One issue is package updates (e.g. of initramfs-tools itself), but by using a configuration snippet -- separate file -- we avoid those because the snippets should be left alone. |

Downstream bug, IRC logs from the user who reported it.
The tl;dr is:
"The initramfs images that are generated by mkinitramfs will have the user:group set to root:root, but their access flags will be 644 (-rw-r--r--). This means that any user or even a script that has read access to the file system can read and extract the secret keyfile from an initramfs image."
initramfs needs to be ran with a different umask here.
The text was updated successfully, but these errors were encountered: