Packagekit lets user install untrusted local packages in Bionic and Focal

Bug #1882098 reported by Sami Niemimäki
264
This bug affects 1 person
Affects Status Importance Assigned to Milestone
packagekit (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

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.

CVE References

affects: aptdaemon (Ubuntu) → packagekit (Ubuntu)
description: updated
Revision history for this message
Esko Järnfors (esko-jarnfors) wrote :

Hi!

Can someone confirm this has been at least read please?

information type: Private Security → Public Security
Revision history for this message
Seth Arnold (seth-arnold) wrote :

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

Revision history for this message
Sami Niemimäki (niemimsa) wrote :

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.

Revision history for this message
Sami Niemimäki (niemimsa) wrote :

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.

Revision history for this message
Julian Andres Klode (juliank) wrote :

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)

Changed in packagekit (Ubuntu):
status: New → Triaged
Revision history for this message
Julian Andres Klode (juliank) wrote :

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.

Revision history for this message
Esko Järnfors (esko-jarnfors) wrote :

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.

Revision history for this message
Julian Andres Klode (juliank) wrote :

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.

Revision history for this message
Julian Andres Klode (juliank) wrote :
tags: added: patch
Revision history for this message
Seth Arnold (seth-arnold) wrote :

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

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

Hi Julian,

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

Thanks!

Revision history for this message
Julian Andres Klode (juliank) wrote :

On it

Revision history for this message
Esko Järnfors (esko-jarnfors) wrote :

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

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

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?

Revision history for this message
Julian Andres Klode (juliank) wrote :

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

Revision history for this message
Julian Andres Klode (juliank) wrote :

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)

Revision history for this message
Esko Järnfors (esko-jarnfors) wrote :

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.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in packagekit (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in packagekit (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in packagekit (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

The updates for this issue have been released:

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

Thanks!

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

Other bug subscribers