/etc/dib-manifests/ has too broad permissions and discloses sensitive information

[George Shuklin]

Some of the options passed to diskimage-builder (for example, DEVUSER_USER_PASSWORD, but the scope of the issue is far beyond devuser element) are highly sensitive and should not be available for reading to non-privileged users in the guest system (f.e. to 'nobody', or to 'www-data').

Diskimage-builder writes directory /etc/dib-manifests into guest system. This directory contains following files with sensitive information and overly relaxed permissions:

-rw-r--r-- 1 root root 105 Mar 10 14:41 dib_arguments
-rw-r--r-- 1 root root 384 Mar 10 14:41 dib_environment
-rw-r--r-- 1 root root 25532 Mar 10 14:42 dib-manifest-dpkg-baremetal-jessie.img

sudo -u nobody cat /etc/dib-manifests/dib_environment
...
declare -x DIB_DEV_USER_PASSWORD="oh_my_god_they_can_see_this"
declare -x DIB_DEV_USER_PWDLESS_SUDO="yes"
declare -x DIB_DEV_USER_USERNAME="debug"
declare -x DIB_DISTRO_NAME="debian"
declare -x DIB_RELEASE="jessie"

TL;DR; diskimage-builder should write those files with 0600 or 0640 permissions, not 0644 permissions.

Affected version (tested so far): 1.9.0.

Used elements to build image: dib-python install-types debootstrap install-static dib-run-parts devuser vm manifests dib-init-system cache-url pkg-map base serverscom-debian-jessie-baremetal cloud-init-datasources bootloader package-installs dpkg

[George Shuklin (george-shuklin)]

Hello. Because there were 3 month grace period and there were zero reaction to this bug I plan to disclose it at the next Monday. If someone want to fix this bug and need more time, please let me know.

[Gregory Haynes (greghaynes)]

Thanks for reporting this.

Do you know of any other places offhand where we may expose a private credential? I agree this is an issue regardless, but I am curious from the standpoint of knowing whether there may be other config options / elements we should document as recommended to not be used (If you notice, the docs for DIB_DEV_USER_PASSWORD say "Set the default password for this user. This is a fairly insecure method of setting the password and is not advised.").

[Jeremy Stanley (fungi)]

Thanks for reporting this! Unfortunately private security bugs for DIB were still under control of the TripleO team until I fixed that just now, so I didn't know about this report until you E-mailed the openstack-dev mailing list about it today. I'll see to it that this gets the attention of some DIB developers as soon as possible, but given your public mention on the ML list I'm going ahead and switching this to public security now so that concerned users of the software can at least take mitigating steps like correcting filesystem permissions or removing those files entirely from their images/servers.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/465655

[Jeremy Stanley (fungi)]

DIB devs: while George's suggestion seems like a good option, would it be possible to also omit/redact known sensitive values there? Or would it break anything if we removed those files from the images entirely?

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/465655
Committed: https://git.openstack.org/cgit/openstack/diskimage-builder/commit/?id=57ef187632c97eb7c2f27207c19f11336b28d97c
Submitter: Jenkins
Branch: master

commit 57ef187632c97eb7c2f27207c19f11336b28d97c
Author: Gregory Haynes <email address hidden>
Date: Wed May 17 08:50:21 2017 -0700

    Set manifests to mode 600 and owner root

    Manifests files can release sensitive information and therefore should
    have restrictive permissions.

    Change-Id: I64d6c830217a7d8b0172df2dc774079dcd1e2a68
    Related-Bug: #1671842

[George Shuklin (george-shuklin)]

Thanks for fix.

I think it should be backported to reported version (1.9) too.

[Jeremy Stanley (fungi)]

At present diskimage-builder doesn't maintain any stable backport branches and just releases from master, but we should at least tag a 2.5.0 release immediately (not 2.4.1 since there are some new dependency exclusions/minimums in master since 2.4.0).

I'll leave it to the DIB developers to determine whether this bug warrants creating new backport branches (especially from a release that is now nearly 1.5 years old).

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/466593
Committed: https://git.openstack.org/cgit/openstack/diskimage-builder/commit/?id=f1369a1add9552ec2f11cc97ee5e9e09f02b49ff
Submitter: Jenkins
Branch: master

commit f1369a1add9552ec2f11cc97ee5e9e09f02b49ff
Author: Noam Angel <email address hidden>
Date: Mon May 22 05:13:34 2017 +0000

    Set manifest permissions in the image

    This is a follow-on to 57ef187632c97eb7c2f27207c19f11336b28d97c.

    There's two things going on here; DIB_MANIFEST_IMAGE_DIR is *outside*
    the chroot on the build host. We copy the files here for posterity, I
    guess. MANIFEST_IMAGE_PATH is *inside* the chroot and are the files
    we want to ensure are locked to root.

    The prior change modified the permissions on DIB_MANIFEST_IMAGE_DIR.
    So the first time you build, it works -- then the second time,
    assuming you're using the same output filename, it hits the root-owned
    manifest directories and causes a build failure.

    I have built with this and checked that the manifest files in the
    image are locked to root:

     $ virt-ls -a ./test.qcow2 -l /etc/dib-manifests
     total 32
     drwxr-xr-x 2 0 0 4096 May 24 03:39 .
     drwxr-xr-x 53 0 0 4096 May 24 03:39 ..
     -rw------- 1 0 0 15236 May 24 03:39 dib-manifest-dpkg-test
     -rw------- 1 0 0 35 May 24 03:39 dib_arguments
     -rw------- 1 0 0 137 May 24 03:39 dib_environment

    Related-Bug: #1671842
    Change-Id: I08319d0b5fcc461d40fe0be8427dcf0e37ad21e6

[Alfredo Moralejo (amoralej)]

1.5 years old?, release 2.0.0 was tagged on Mar 13, 2017, and last 1.x release was 1.28.0 tagged on Mar, 2nd. IMO, a stable release 1.28.x should be created to backport critical bugs and fixes. Note that distros or users deploying openstack newton or ocata will probably not bump dib to 2.0 until pike for those cases where dib is used by other projects, as tripleo.

[Jeremy Stanley (fungi)]

George said "it should be backported to reported version (1.9)" which is ~1.5 years old.

[George Shuklin (george-shuklin)]

It was my mistake. I mean to last supported 1.x series. I looked into git tag output and 1.9 was at the bottom. Yes, 1.28 seems as a good target.

[Ian Wienand (iwienand)]

This "1.X" series v "2.0" series is a bit of misnomer and almost exclusively internal changes. I'd be quite confident nobody calling dib from the command line would notice a difference between the two (the only issue we had was with instack, which was using arguably internal python interfaces ... at least, it wasn't well thought out between the two teams). I do not believe anyone pinned themselves to 1.28.0 to avoid 2.0.0. This was all put out there in [1]. ergo, 1.28.0 was mostly a safety release so that if v2 *did* explode for some unknown reason, we could do a v1 branch off it. But this does not appear to have happened, thankfully.

Thus, if somebody has pinned themselves to an old dib release but decides to update, tries >= 2.5.0, reports to us that it doesn't work as a drop-in replacement for them, and it's not something we can trivially fix for them quickly, and 1.28.0 works for them, and they have a specific need for this fix, I would entertain figuring out if activating this branch is the appropriate solution.

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-February/111833.html

[George Shuklin (george-shuklin)]

I think this bug is fixed. Isn't it?

[Ian Wienand (iwienand)]

We fixed this