Skip to content
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

Closed
tsimonq2 opened this issue Jul 2, 2019 · 13 comments

Comments

Projects
None yet
5 participants
@tsimonq2
Copy link
Contributor

commented Jul 2, 2019

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.

adriaandegroot added a commit that referenced this issue Jul 2, 2019

@teward

This comment has been minimized.

Copy link

commented Jul 2, 2019

This issue has been assigned the CVE ID of CVE-2019-13179 by MITRE.

@Ofirnir123

This comment has been minimized.

Copy link

commented Jul 3, 2019

Hi! according to Mitre all the versions up to 3.2.4 are vulnerable.
Can you relate if this issue was already fixed and from which version ?

Kind regards :D

@adriaandegroot

This comment has been minimized.

Copy link
Contributor

commented Jul 3, 2019

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.

@teward

This comment has been minimized.

Copy link

commented Jul 3, 2019

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

@adriaandegroot

This comment has been minimized.

Copy link
Contributor

commented Jul 4, 2019

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.

@kkofler

This comment has been minimized.

Copy link
Contributor

commented Jul 4, 2019

Please note, however, that dracut is not affected: Dracut does not require the caller (Calamares in this case) to set the umask, it already does this automatically, and has been doing so since 2012 (since 2016 for one special case). See CVE-2012-4453 (dracutdevs/dracut@e1b4899) and CVE-2016-8637 (dracutdevs/dracut@0db9891).

Issue #1190 (CVE-2019-13178) affects all distributions regardless of initramfs generator though.

@kkofler

This comment has been minimized.

Copy link
Contributor

commented Jul 4, 2019

Since the initramfs module was fixed and the dracut module is not affected, only the initcpio module remains to be fixed in upstream Calamares. If distributions have downstream modules for other initramfs generators, those may or may not be affected by this issue, depending on what the initramfs generator does.

@adriaandegroot

This comment has been minimized.

Copy link
Contributor

commented Jul 4, 2019

Screenshot_20190705_004330

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 umask 077 before calling the update script. But at this point I don't think it's actually a Calamares issue:

  • in the installed system, I logged in, switched to a root bash
  • In /boot, make the initrd file 0600 and set umask 077
  • checked that the initrd had the right permissions and generated a new one
  • in spite of the umask, the generated initrd has world-readable permissions

So the (re)generation process is ignoring umask anyway.

I was going to say "and the cryptfile isn't in there anyway, since cpio -i -t < /boot/initrd doesn't list it", but unmkinitramfs does something different, and does extract the key file.

@adriaandegroot

This comment has been minimized.

Copy link
Contributor

commented Jul 4, 2019

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.

@adriaandegroot

This comment has been minimized.

Copy link
Contributor

commented Jul 4, 2019

Line 3 of /usr/sbin/mkinitramfs in an installed lubuntu system reads

umask 0022
@adriaandegroot

This comment has been minimized.

Copy link
Contributor

commented Jul 4, 2019

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 /etc/initramfs.conf when LUKS is used, or perhaps always, as a security measure.

@adriaandegroot

This comment has been minimized.

Copy link
Contributor

commented Jul 4, 2019

(that's /etc/initramfs-tools/initramfs.conf)

@adriaandegroot

This comment has been minimized.

Copy link
Contributor

commented Jul 5, 2019

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:

  • distro's should fix up their configurations for initramfs to be more secure anyway, referring to CVE-2012-4453 as well (pointed out by Kevin).
  • Calamares can drop a configuration snippet in /etc/initramfs-tools/conf.d to do the actual work.

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.

adriaandegroot added a commit that referenced this issue Jul 5, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.