Packagekit lets user install untrusted local packages in Bionic and Focal

[Sami Niemimäki]

We have packagekit configured to allow users to install trusted packages from preconfigured repositories, but disallowed them to install any untrusted packages.

The policykit configuration we use is following:

[tld.univ.packagekit]
Identity=unix-group:adm;
Action=org.freedesktop.packagekit.package-install;org.freedesktop.packagekit.package-reinstall;org.freedesktop.packagekit.package-remove;org.freedesktop.packagekit.system-sources-refresh;org.freedesktop.packagekit.system-update;org.freedesktop.packagekit.repair-system;
ResultAny=auth_self
ResultActive=auth_self
ResultInactive=auth_self

[tld.univ.packagekit-deny]
Identity=unix-user:*;
Action=org.freedesktop.packagekit.package-install-untrusted;
ResultAny=no

We would expect this to prevent users from installing local packages downloaded from random repositories, however this does not seem to be the case.

pkcon install-local random_package.deb will happily prompt for the user to authenticate and will install the package, while pkcon --allow-untrusted install-local random_package.deb will prompt for root password, which the user does not have.

Our initial toughts was that the issue would be in packagekitd, but after further investigations it looks like the issue could be in aptcc backend.

We are more than happy to provide you with further details, but the above should be enough to reproduce the issue.

[Esko Järnfors (esko-jarnfors)]

Hi!

Can someone confirm this has been at least read please?

[Seth Arnold (seth-arnold)]

Hello Sami, Esko,

I'm not very familiar with the packagekit or policykit frameworks, so please forgive me if I'm far off course here with these thoughts:

- Is the [tld.univ.packagekit-deny] rule necessary? I'd hope that this permission wouldn't be granted to anyone but admins.

- Are there other rules in other files that might have granted this permission?

- Does it matter if the test users are in no groups? just their own username-group? adm? sudo?

- Does polkit or packagekit have a way to see which rules allow or deny any given request?

Thanks

[Sami Niemimäki (niemimsa)]

Hello Seth,

the packagekit-deny rule should not be necessary, it's there to underline what is specifically not allowed.

AFAIK, there are no other rules which could have granted this permission. This happens on a fresh install of Ubuntu where the above is the only modification to polkit rules.

I'm on vacation since yesterday evening, so I cannot currently check if the groups have some kind of unexpected effect.

See this for reference:
https://github.com/hughsie/PackageKit/blob/master/policy/org.freedesktop.packagekit.policy.in

The issue is that the command 'pkcon install-local evil-package-i-just-created.deb' triggers the action 'org.freedesktop.packagekit.package-install' instead of 'org.freedesktop.packagekit.package-install-untrusted' which it should.

[Sami Niemimäki (niemimsa)]

Hello Seth,

I can now confirm that it does not matter if the test users are in no groups.

The issue persists.

Lines 49 to 56 in the link I provided earlier describe the package-install-untrusted action which should be triggered when installing local packages:

<action id="org.freedesktop.packagekit.package-install-untrusted">
    <!-- SECURITY:
          - Normal users require admin authentication to install untrusted or
            unrecognised packages, as allowing users to do this without a
            password would be a massive security hole.
          - This is not retained as each package should be authenticated.
     -->
    <description>Install untrusted local file</description>

AFAIK this works as intended with other than aptcc backends, eg in Red Hat.

[Julian Andres Klode (juliank)]

Yup, install-local does indeed trigger package-install not package-install-untrusted

Aug 28 11:28:53 jak-t480s polkitd(authority=local)[1744]: Operator of unix-session:2 FAILED to authenticate to gain authorization for action org.freedesktop.packagekit.package-install for system-bus-name::1.535 [pkcon install-local xterm_353-1ubuntu1_amd64.deb] (owned by unix-user:jak)

[Julian Andres Klode (juliank)]

I found out the cause for this, but other backends are affected too probably
- basically the packagekit daemon assumes that packages can be trusted themselves,
so backends that do not have trust information in packages need to explicitly
reject local packages as untrusted, so that PackageKit reprompts for trusted.

I'm not sure how to proceed there - I can come up with a fix for aptcc, but
upstream can't put in the work for other backends, but then releasing just an
apt fix while other backends are vulnerable would not be a good call either.

[Esko Järnfors (esko-jarnfors)]

Thanks for triaging and investigating this, Julian!

A fix for at least the aptcc backend would be highly appreciated -- I'd hope the other backends will fix this on their own if they care about it.

The point of packagekit+policykit is to enable people to do (at least somewhat limited) stuff without explicit root access -- otherwise you'd just give them sudo rights and be done with it. In the current situation, granting a user the right to install ("trusted") packages actually grants them rights to place arbitrary files in the filesystem and execute arbitrary code (package scripts) as root, which is at the very very least highly misleading.

I took a cursory look at the earlier apt backend written in python (which is now deleted from the packagekit tree) and it at least looked like it had some logic to decide whether a package can be trusted or not so it didn't seem like checking where the package is coming from would be unprecedented.

[Julian Andres Klode (juliank)]

It asks apt if the package is trusted, and from apt's POV it is. which might or might not be good, UX wise, for apt (maybe it should also tell you that local debs are not verified), but not much of an issue there.

[Seth Arnold (seth-arnold)]

Please use CVE-2020-16122 for this issue. Thanks.

[Marc Deslauriers (mdeslaur)]

Hi Julian,

Could you please backport the patch in comment #9 to xenial? The code in xenial is substantially different.

Thanks!

[Julian Andres Klode (juliank)]

On it

[Esko Järnfors (esko-jarnfors)]

Hi and thanks everyone!

I tested the patch and it works fine on focal (packagekit-1.1.13), but even though it applies, it doesn't fix this on bionic (packagekit-1.1.9).

[Marc Deslauriers (mdeslaur)]

I am currently preparing updates for this issue, and I just tested the bionic update that includes this patch, and it works in my environment.

Could you please make sure you created the policy file ok, and have rebooted after updating packagekit?

[Julian Andres Klode (juliank)]

Easiest is to just look at policykit log and see that it triggers the untrusted action, fwiw. IMO.

[Julian Andres Klode (juliank)]

Attached patch for xenial, but I can't test it.

$ pkcon install-local xterm_353-1ubuntu1_amd64.deb
Installing files [=========================]
Finished [=========================]
Fatal error: MIME type 'application/vnd.debian.binary-package' not supported /home/jak/Downloads/xterm_353-1ubuntu1_amd64.deb

(trying with a random deb, in lxd container)

[Esko Järnfors (esko-jarnfors)]

I checked the patch again on bionic, turns out I missed the packagekit restart the first time and the package postinst script for one reason or another didn't restart the daemon on my test machine as it did on focal. The patch seems to work on bionic as well.

[Launchpad Janitor (janitor)]

This bug was fixed in the package packagekit - 1.1.13-2ubuntu1.1

---------------
packagekit (1.1.13-2ubuntu1.1) focal-security; urgency=medium

  * SECURITY UPDATE: information disclosure (LP: #1888887)
    - debian/patches/CVE-2020-16121.patch: hide failures behind a single
      error message in src/pk-transaction.c.
    - CVE-2020-16121
  * SECURITY UPDATE: untrusted local file installation (LP: #1882098)
    - debian/patches/CVE-2020-16122.patch: do not trust local packages in
      backends/aptcc/apt-intf.cpp.
    - CVE-2020-16122

 -- Marc Deslauriers <email address hidden> Wed, 23 Sep 2020 06:55:22 -0400

[Launchpad Janitor (janitor)]

This bug was fixed in the package packagekit - 1.1.9-1ubuntu2.18.04.6

---------------
packagekit (1.1.9-1ubuntu2.18.04.6) bionic-security; urgency=medium

  * SECURITY UPDATE: information disclosure (LP: #1888887)
    - debian/patches/CVE-2020-16121.patch: hide failures behind a single
      error message in src/pk-transaction.c.
    - CVE-2020-16121
  * SECURITY UPDATE: untrusted local file installation (LP: #1882098)
    - debian/patches/CVE-2020-16122.patch: do not trust local packages in
      backends/aptcc/apt-intf.cpp.
    - CVE-2020-16122

 -- Marc Deslauriers <email address hidden> Wed, 23 Sep 2020 07:01:04 -0400

[Launchpad Janitor (janitor)]

This bug was fixed in the package packagekit - 0.8.17-4ubuntu6~gcc5.4ubuntu1.5

---------------
packagekit (0.8.17-4ubuntu6~gcc5.4ubuntu1.5) xenial-security; urgency=medium

  * SECURITY UPDATE: information disclosure (LP: #1888887)
    - debian/patches/CVE-2020-16121.patch: hide failures behind a single
      error message in src/pk-transaction.c.
    - CVE-2020-16121
  * SECURITY UPDATE: untrusted local file installation (LP: #1882098)
    - debian/patches/CVE-2020-16122.patch: do not trust local packages in
      backends/aptcc/apt-intf.cpp.
    - CVE-2020-16122

 -- Marc Deslauriers <email address hidden> Wed, 23 Sep 2020 13:23:04 -0400

[Marc Deslauriers (mdeslaur)]

The updates for this issue have been released:

https://ubuntu.com/security/notices/USN-4538-1

Thanks!