Snap kernel build process installs unauthenticated packages

Hello Sachi - Thanks for reporting this issue! We agree that the use of the --allow-insecure-repositories and --allow-unauthenticated options is poor form and should not be used in the makefiles for building kernel snaps.

In practice, I think that this would be difficult to attack since the traffic between the builders and launchpad itself should be well controlled. There's obviously no sense in leaving that attack vector open so we'll get it fixed up. As you correctly pointed out, fixing it also benefits end-users that attempt to use the affected makefile target.

Thanks again! We'll be working to fix this issue.

Please use CVE-2019-11480 for both --allow-insecure-repositories and --allow-unauthenticated.

Thanks

I did some work on this and got to know the makefile and its purpose a
little better. I'm able to respond to more of the initial bug report
now.

On 2019-07-15 20:48:06, Launchpad Bug Tracker wrote:
> Inside these Makefiles, it uses a number of hardcoded http URLS.

To be clear, this is not a security issue. Ubuntu uses http URLs for apt
archives. The files served over http are signed and then verified by the
client.

I'll update the bug title to remove the mention of http mirrors being an
issue.

> One is a PPA URL to launchpad, which should be paramaterised (I can't hit it
> from a corporate network), and the other is a paramaterised URL hard-
> coded to use 'http'.

You can override the use of the ftpmaster.internal/ubuntu mirror URL
using the MIRROR make variable like so:

 $ sudo make KERNEL=linux-pc-image MIRROR=us.archive.ubuntu.com

> The pramaterised endpoint is `ftpmaster.internal/ubuntu` by default,
> and should probably point to 'http://archive.ubuntu.com/ubuntu/' or
> something that is buildable by end-users as well, especially seeing as
> it is the default if building from the snapcraft.yaml file, see
> following link, sets 'PROPOSED=true' in the 'make-parameters' section
> of the build.

The default mirror used is a separate, non-security issue and should not
be tracked by this particular bug report.

Here's my proposed fix for the Bionic tree. I was able to verify that the 'all' target works as expected in a pristine Bionic amd64 VM using the following command:

  $ sudo make KERNEL=linux-pc-image MIRROR=us.archive.ubuntu.com DESTDIR=dest all

I compared the output of that command with and without my patch applied to verify that no unauthenticated repositories/packages are being used once that patch is applied.

Here's my proposed fix for the Xenial tree. I was able to verify that the 'all' target works as expected in a pristine Xenial amd64 VM using the following command:

  $ sudo make KERNEL=linux-pc-image MIRROR=us.archive.ubuntu.com DESTDIR=dest all

I compared the output of that command with and without my patch applied to verify that no unauthenticated repositories/packages are being used once that patch is applied.

I noticed that a cosmic tree exists and it is also affected:

  https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-snap/+git/cosmic

However, I don't believe that is used at all. I'd prefer that we simply remove that git tree rather than patch its Makefile.

@tyhicks confirmed there should not be a repository for cosmic. I will ensure it is gone.

@tyhick, to spread the info, we had to make some iterations over the bionic change (and the xenial one likely needs the same) because in the build environment it seems the additional repo is already added for the build environment. So as soon as you copy the outside sources.list into the chroot the dist-upgrade fails. We ended with a sequence of:

1. debootstrap
2. apt-get update inside
3. install gnupg inside
4. add the key inside
5. copy the outside repo into inside
6. add the additional repo inside (pointless in buildenv but meh)
7. run apt-get update inside
8. run apt-get dist-upgrade inside

Thanks! That sequence seems fine to me.

On Tue, Jul 16, 2019 at 06:50:10AM -0000, Tyler Hicks wrote:
> I noticed that a cosmic tree exists and it is also affected:

> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-
> snap/+git/cosmic

> However, I don't believe that is used at all. I'd prefer that we simply
> remove that git tree rather than patch its Makefile.

Is there a tree/branch for UC20 work? UC20 series snaps are going to differ
quite a bit from UC18 due to initramfs handling, but I don't want to assume
that they will fix this particular bug as a side-effect.

The UC20 tree if it exists should certainly not be based on cosmic at this
point.

On 2019-07-16 15:14:48, Steve Langasek wrote:
> On Tue, Jul 16, 2019 at 06:50:10AM -0000, Tyler Hicks wrote:
> > I noticed that a cosmic tree exists and it is also affected:
>
> > https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-
> > snap/+git/cosmic
>
> > However, I don't believe that is used at all. I'd prefer that we simply
> > remove that git tree rather than patch its Makefile.
>
> Is there a tree/branch for UC20 work? UC20 series snaps are going to differ
> quite a bit from UC18 due to initramfs handling, but I don't want to assume
> that they will fix this particular bug as a side-effect.

No, a tree/branch for UC20 does not yet exist.

The makefiles have now been updated for bionic and xenial (test pending for xenial on the respin done).

CVE-2019-11480 has not yet been published and/or updated. It appears this security issue has been addressed. If so, please publish related CVE information to public databases.

I have updated our CVE tracker[1] to include the various details of this CVE - the associated web version of this should be regenerated soon and be visible at [2] - this will be forwarded to MITRE later.

[1] https://git.launchpad.net/ubuntu-cve-tracker/commit/?id=fe9fe52e12c6a9b445428e2883d7a4ce253aeb13
[2] https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-11480.html