[SRU] blocks boot on core18

Bug #1783810 reported by Michael Vogt on 2018-07-26
This bug affects 1 person
Affects Status Importance Assigned to Milestone
util-linux (Ubuntu)
Sergio Cazzolato
Sergio Cazzolato

Bug Description

The current version of libuuid is using getrandom() without the GRND_NONBLOCK flag. This means that in early boot the boot is blocked until the crng is initialized to "level=1" which on virtual machines may take some time.

Upstream fixed this in https://github.com/karelzak/util-linux/commit/a9cf659e0508c1f56813a7d74c64f67bbc962538 and we should just backport the fix.

 * Makes systems that use libuuid in early boot hang

[Test Case]
 * boot a fresh core18 system with kernel 4.15

[Regression Potential]
 * little, change is very targeted

This is uploaded to the bionic-proposed queue now.

Michael Vogt (mvo) on 2018-07-26
Changed in util-linux (Ubuntu):
status: New → Fix Released
description: updated
description: updated
Robie Basak (racb) wrote :

Hi Michael,

What else uses this function, and does it do it in a security sensitive way whose behaviour is now changed possibly for the worse? I understand that the change is from upstream so they consider it OK, but that doesn't placate my concern completely.

Second, I found https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/lib/randutils.c?id=edc1c90cb972fdca1f66be5a8e2b0706bd2a4949, which was committed very soon after the patch you've uploaded. In that description it says "Note that we do not use random numbers for security sensitive things like keys or so. It's used for random based UUIDs etc" so I guess that answers part of my first question. But that change is currently also in Cosmic. It might (whether accidentally or intentionally) fix a problem introduced by the first commit, so perhaps we should also cherry-pick that? What do you think?

Finally, is there any security implication if an attacker can predict generated UUIDs in our use cases? For example what if an attacker can inject a prepared disk image and get that mounted instead of one that we intend by guessing our filesystem UUID? Does that fall within our threat model? I'm wondering if this is different from upstream's threat model for us because of our use of cloud images.

So I guess there are two things I'd like, please:

1) Your comment on whether we should also pick the following commit from upstream in this SRU.

2) A security team ack on this change.



Hello Michael, or anyone else affected,

Accepted util-linux into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/util-linux/2.31.1-0.4ubuntu3.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in util-linux (Ubuntu Bionic):
status: New → Fix Committed
Michael Vogt (mvo) wrote :

Thanks for your careful review Robie! As far as security is concerned, upstream comments on this in edc1c90cb972fdca1f66be5a8e2b0706bd2a4949:
   Note that we do not use random numbers for security sensitive things
   like keys or so. It's used for random based UUIDs etc.

I looked at the util-linux source and it is used in:
* dos.c: create a random disk ID
* ipcmk.c: create shared memory segments with a random key
* gen_uuid.c: generate UUIDs
* mcookie.c: to generate 128bit random numbers for xauth but the man-page warns that the randomness of this may come from the libc pseudo-random functions

Marc Deslauriers (mdeslaur) wrote :

I think this is acceptable from a security point of view, especially since this is an upstream change.

Before randutils.c implemented support for the getrandom() call, it used /dev/urandom. The patch simply falls back to using /dev/urandom if there is no enough entropy for getrandom().

Marc Deslauriers (mdeslaur) wrote :

s/from a security/from the security team's/

I validated this by using this new core18 image http://people.canonical.com/~mvo/tmp/core18-amd64-18-alpha20180803-with-lp1783810.img.xz
It is working now

Changed in util-linux (Ubuntu):
assignee: nobody → Sergio Cazzolato (sergio-j-cazzolato)
Changed in util-linux (Ubuntu Bionic):
assignee: nobody → Sergio Cazzolato (sergio-j-cazzolato)
status: Fix Committed → Fix Released
Michael Vogt (mvo) wrote :

The above image was build by manually adding the patched util-linux libuuid.so to the initramfs. The kernel (snap) build system does not use -proposed so the initrd had to be updated this way to test this on core.

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

Other bug subscribers