Bug 717566 (CVE-2011-2515) - CVE-2011-2515 PackageKit: installs unsigned RPM packages as though they were signed
Summary: CVE-2011-2515 PackageKit: installs unsigned RPM packages as though they were ...
Keywords:
Status: CLOSED WONTFIX
Alias: CVE-2011-2515
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 718127 718128 807127
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-29 09:09 UTC by Peter Robinson
Modified: 2019-09-29 12:45 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-10 10:57:52 UTC


Attachments (Terms of Use)
Auth dialog box (28.26 KB, image/png)
2011-06-29 09:09 UTC, Peter Robinson
no flags Details
Upstream fix (4.34 KB, patch)
2011-07-01 08:41 UTC, Richard Hughes
no flags Details | Diff

Description Peter Robinson 2011-06-29 09:09:26 UTC
Created attachment 510417 [details]
Auth dialog box

when installing a self built unsigned rpm that I downloaded using epiphany I get an authentication dialog stating that Authentication is required to install a signed package (screen shot attached). I believe this is wrong in two cases:
- The package wasn't signed
- I don't believe authentication is required for a signed Package with a key that's already installed.

Versions are:
PackageKit-device-rebind-0.6.15-1.fc15.x86_64
PackageKit-0.6.15-1.fc15.x86_64
PackageKit-yum-plugin-0.6.15-1.fc15.x86_64
PackageKit-yum-0.6.15-1.fc15.x86_64
PackageKit-gtk-module-0.6.15-1.fc15.x86_64
PackageKit-gstreamer-plugin-0.6.15-1.fc15.x86_64
PackageKit-glib-0.6.15-1.fc15.x86_64
PackageKit-gtk3-module-0.6.15-1.fc15.x86_64

Comment 1 Elad Alfassa 2011-06-29 13:17:08 UTC
What's the output of 
rpmdev-checksig package.rpm
(replace package.rpm with the name of the package you've downloaded).




-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 2 Peter Robinson 2011-06-29 14:32:45 UTC
I didn't keep the rpm around, but running it against the installed one I get this.

$ rpm -qi gnome-shell-extension-pidgin-0-0.2.git4ca78b1.fc14.x86_64
Name        : gnome-shell-extension-pidgin
Version     : 0
Release     : 0.2.git4ca78b1.fc14
Architecture: x86_64
Install Date: Wed 29 Jun 2011 09:55:27 AM BST
Group       : User Interface/Desktops
Size        : 40774
License     : GPLv2+
Signature   : (none)
Source RPM  : gnome-shell-extension-pidgin-0-0.2.git4ca78b1.fc14.src.rpm
Build Date  : Wed 29 Jun 2011 09:52:27 AM BST
Build Host  : x86-13.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : https://github.com/kagesenshi/gnome-shell-extensions-pidgin
Summary     : The components necessary to integrate Pidgin with GNOME Shell
Description :
This package contains the necessary components to integrate pidgin with
GNOME Shell:
* Izhar Firdaus's GNOME Shell Extension to display Pidgin chats as
  notifications in the Shell message tray.
* Wojtek Surówka's Pidgin status notifier plugin

In order to activate these components, you will need to:
* Be running Pidgin (the extension uses Pidgin's DBUS API)
* Restart GNOME Shell after installation
* Enable the "GNOME Shell Connector" plugin within Pidgin


$ rpmdev-checksig gnome-shell-extension-pidgin-0-0.2.git4ca78b1.fc14.x86_64
gnome-shell-extension-pidgin-0-0.2.git4ca78b1.fc14.x86_64: FAILED - None <None>

Comment 3 Richard Hughes 2011-06-29 15:48:05 UTC
Sure, I can reproduce this bug. Marking as security sensitive until we know what the problem is.

Comment 4 Richard Hughes 2011-06-29 16:31:00 UTC
This is a API change in yum that has caused a security bug.

The following yum commit changes the default behavior of _checkSignatures() when using local packages:

--------------------
commit 290933489b1aaeb1017d10fb59ccf3231e309115
Author: Seth Vidal <skvidal@fedoraproject.org>
Date:   Thu Sep 30 16:28:30 2010 -0400

    add localpkg_gpgcheck option to [main] so users can set whether or not
    to gpgcheck pkgs in local files
    
    documents it too
--------------------

Using a trivial reproducer,

--------------------
#!/usr/bin/python
import yum
import sys
from yum.packages import YumLocalPackage
yb = yum.YumBase()
po = YumLocalPackage(ts=yb.rpmdb.readOnlyTS(), filename=sys.argv[1])
try:
    yb._checkSignatures([po], None)
except yum.Errors.YumGPGCheckError, e:
    print "The package %s IS NOT okay" % po.name
else:
    print "The package %s IS okay" % po.name
--------------------

You can tests by saving the snippet as test.py, and then doing "python ./test.py /path/to/an/unsigned.rpm"

You can see that releases prior to this change report the argv[1] as unsigned, and therefor requiring the untrusted-package PolicyKit authorization, and releases after this commit report argv[1] as signed, and therefor requiring the lesser trusted-package authorization.

NOTE: a user can update trusted packages without a password on all recent Fedora releases. I don't think this bug can be used to install new local packages as part of an upgrade, as UpdatePackages and UpdateSystem do not use YumLocalPackage.  It would be very easy to convince somebody that a local rpm package was signed (and thus trusted) and that is was safe to install with a little social engineering.

Richard.

Comment 5 seth vidal 2011-06-29 19:18:44 UTC
It's not an API change it is a behavior change, however.

We intentionally made the default behavior for local rpms to allow unsigned.

I believe we discussed, briefly, making the config for fedora be localpkg_gpgcheck=1 but I'm not sure what was decided with that or not.

I don't see this as a security bug at all.

Comment 6 James Antill 2011-06-29 19:27:12 UTC
 I know we'd discussed the default in relation to the cli ... and after a bit of thought it seemed pretty obvious that the default should be false, for the cli.

 We probably didn't think much of any GUI using those code paths, or what the right default might be for them. But then the patch was posted to the devel list (like all patches), and had more than just a simple ACK reponse. And it was specifically mentioned in the rpm changelog entry when it went into rawhide. And that was 9 months ago ... so we also hadn't realized people were unaware of it.

 We can look at adding something, if you need it, to allow people to change the default for the GUI and CLI separately.

Comment 7 Peter Robinson 2011-06-29 19:50:56 UTC
People. Please review the bug. The bug I reported was the text in the diaglog box is wrong (see the attachment). The dialog text states "Authentication is required to install a signed package" where as the package was not signed. I believe the text should read "Authentication is required to install a UNSIGNED package" 

The fact that I need to authenticate to install a non signed package I believe is correct, its just the wording in the dialog box (and possibly the detection of the fact that its signed or not) is incorrect.

Comment 8 Richard Hughes 2011-06-29 20:20:36 UTC
>James Antill <james.antill@redhat.com> changed:
>           What    |Removed                     |Added
>----------------------------------------------------------------------------
>          Component|yum                         |PackageKit
>         AssignedTo|skvidal@sethdot.org         |richard@hughsie.com

Really? Are you joking with me? YUM changes the default for functionality another component relies on which causes a security bug in another component? 

The core problem is that the behavior changed. If you wanted to make that change in yum, at least some co-ordination between you guys and the principal user in Fedora (PackageKit) is the very least you have to do.

(In reply to comment #5)
> It's not an API change it is a behavior change, however.

PackageKit uses the API of yum. The API call that used to work, no longer works. PackageKit used that API to make a security decision.

> I believe we discussed, briefly

Nobody even mentioned it to me. Do I have to look at every commit to yum ensuring something isn't going to break PackageKit?

If there's no such guarantee of API ("behavior", whatever) stability between minor releases then maybe PackageKit shouldn't be using yum at all. 

> I don't see this as a security bug at all.

It is. It's a security bug that allows users to install unsigned packages with all the indications so that they think the package is signed. If the admin has setup PolicyKit so that users in the wheel group can install signed packages without a password (not-uncommon in single user machines) then with the yum "behavior" change means any unsigned rpm can now be installed without a password.

(In reply to comment #7)
> The bug I reported was the text in the diaglog
> box is wrong (see the attachment).

No, the dialog is correct, as yum is telling PackageKit that the package is signed, when it's really unsigned. Reverting the commit in yum means you get the correct "unsigned" dialog from PackageKit for unsigned packages.

Richard.

Comment 9 James Antill 2011-06-29 22:06:43 UTC
(In reply to comment #8)

> (In reply to comment #5)
> > It's not an API change it is a behavior change, however.
> 
> PackageKit uses the API of yum. The API call that used to work, no longer
> works. PackageKit used that API to make a security decision.

The public API is, and has been since 2007, documented as:

        Take a package object and attempt to verify GPG signature if required

        Returns (result, error_string) where result is:
            - 0 - GPG signature verifies ok or verification is not required.
            - 1 - GPG verification failed but installation of the right GPG key
                  might help.
            - 2 - Fatal GPG verification error, give up.

...it's hard to see how you can read this as "0 == package has a signature and it verifies".
 That API calls another API which is, and has been since 2004, documented as:

    """Takes a transaction set and a package, check it's sigs, 
    return 0 if they are all fine
    return 1 if the gpg key can't be found
    return 2 if the header is in someway damaged
    return 3 if the key is not trusted 
    return 4 if the pkg is not gpg or pgp signed"""

...which appears to be the behaviour PK actually wanted ... why you decided to use the first API instead of the second API, I couldn't say. However the change we did is obviously within the bounds for what the first API is documented to do.

> The core problem is that the behavior changed. If you wanted to make that
> change in yum, at least some co-ordination between you guys and the principal
> user in Fedora (PackageKit) is the very least you have to do.

The behaviour changed within spec. Saying "PK is the principal user" is no doubt true from your POV, but the pulp people have a different POV as do the anaconda people as do etc. etc. etc. The assumption that we should check all behaviour changes against all the code that uses them is ... unique.

> It is. It's a security bug that allows users to install unsigned packages with
> all the indications so that they think the package is signed.

I'm sure Seth meant that it's not a security bug from the yum point of view, we specifically wanted "yum install foo.rpm" to install foo.rpm without the user having to disable all gpg checking.
How big of a security problem it is for gpk/etc. is debatable, but it does look like it might be at least a minor one.

Comment 12 Richard Hughes 2011-06-30 07:07:19 UTC
(In reply to comment #9)
> (In reply to comment #8)
> The public API is, and has been since 2007, documented as:
>         Take a package object and attempt to verify GPG signature if required

You've hit the nail on the head. PackageKit explicitly sets yumbase.conf.gpgcheck=1 so that the correct signature *is* required. With the change, I have to set yumbase.conf.localpkg_gpgcheck=1 for the same behavior.

the condition for the "if required" has changed in the yum API.

> The behaviour changed within spec. Saying "PK is the principal user" is no
> doubt true from your POV, but the pulp people have a different POV as do the
> anaconda people as do etc. etc. etc. The assumption that we should check all
> behaviour changes against all the code that uses them is ... unique.

PackageKit is the only software the uses yum that is running on every Fedora install by default. Anaconda is a one-shot thing, and pulp installed manually.

> I'm sure Seth meant that it's not a security bug from the yum point of view, we
> specifically wanted "yum install foo.rpm" to install foo.rpm without the user
> having to disable all gpg checking.

Sure, and from the yum CLI, as root, that probably makes sense. But if somebody had emailed me with a "heads up, you probably should be using this method rather than that method" or "if you want to use that, you'll need to set yumbase.conf.localpkg_gpgcheck=1 in your next release" then we wouldn't be where we're at now.

Comment 13 Richard Hughes 2011-06-30 14:20:00 UTC
James, Seth: Is yum-3.2.29 already pushed to RHEL5, RHEL6, F15 and F16?

Vincent: Does this need to be embargoed with a CVE and that kind of thing or should it just be treated like any other bug given you think it's low-severity? I'd appreciate any help with this if the bug affects RHEL as well.

Thanks,

Richard.

Comment 15 James Antill 2011-06-30 16:24:32 UTC
We rarely update Fedora...

Fedora 13 never got an update and 14 is unlikely to get one.

Fedora 15 is more likely to, but even that is far from a certainty.

rawhide gets updates fairly often, but they don't all go into Fed-16 when it branches (much more often than release updates -- but then some is a lot more than none).


On the other side, there's also the yum-rawhide rebuild repo. 

   http://repos.fedorapeople.org/repos/james/yum-rawhide/

...if you want newer versions to test on older releases.

Comment 16 Vincent Danen 2011-06-30 17:29:30 UTC
(In reply to comment #13)
> James, Seth: Is yum-3.2.29 already pushed to RHEL5, RHEL6, F15 and F16?
> 
> Vincent: Does this need to be embargoed with a CVE and that kind of thing or
> should it just be treated like any other bug given you think it's low-severity?
> I'd appreciate any help with this if the bug affects RHEL as well.

Hi Richard.

It would need a CVE, but this is a pretty low impact vulnerability.  I've come up with a preliminary CVSSv2 score of 1.5/AV:L/AC:M/Au:S/C:N/I:P/A:N (I believe Au:S is correct as you would have to authenticate with PackageKit in order to get the package installed regardless of its signed state).

RHEL5 currently has 3.2.22-33.el5 so we should be safe there (assuming this was introduced in 3.2.29) but the concern about backports is valid.  We have to ensure that if this functionality gets backported in RHEL5 that we also fix PackageKit at the same time to accommodate the change.

As I understand it, the basic problem here is that yum changed what PackageKit was relying on, and the end result is that a user can install an unsigned package without a GPG check, but be told by PackageKit that it is in fact signed (and trusted).  It still requires a user to download said unsigned package manually (or from a rogue repo that is already setup) and also requires authentication to install the package.  Does that pretty much sum up the problem?

I do not believe we would ASYNC PackageKit in this case, so perhaps we can obtain a slot in 6.2 to get this corrected there?

If there are no disagreements to the above, I'll move this to an SRT bug and note the appropriate affects, give it a CVE name, etc.  I do not think we need to embargo this at all, we can certainly make it public and get it fixed in Fedora right away.

Comment 17 Richard Hughes 2011-06-30 18:36:54 UTC
(In reply to comment #16)
> As I understand it, the basic problem here is that yum changed what PackageKit
> was relying on, and the end result is that a user can install an unsigned
> package without a GPG check, but be told by PackageKit that it is in fact
> signed (and trusted).  It still requires a user to download said unsigned
> package manually (or from a rogue repo that is already setup) and also requires
> authentication to install the package.  Does that pretty much sum up the
> problem?

Yes, sums it up nicely. By default, users still have to authenticate to install software, but quite a few users will have manually turned off this check for signed (trusted) software.

> I do not believe we would ASYNC PackageKit in this case, so perhaps we can
> obtain a slot in 6.2 to get this corrected there?

Sounds good to me.

> If there are no disagreements to the above, I'll move this to an SRT bug and
> note the appropriate affects, give it a CVE name, etc.  I do not think we need
> to embargo this at all, we can certainly make it public and get it fixed in
> Fedora right away.

Excellent, I'll fix upstream and Fedora tomorrow. Thanks for the help.

Richard.

Comment 18 Vincent Danen 2011-07-01 04:34:47 UTC
I've assigned the name CVE-2011-2515 to this issue.  When you correct this upstream, please note the CVE name.

Comment 19 Vincent Danen 2011-07-01 04:40:50 UTC
Acknowledgements:

Name: Peter Robinson

Comment 20 Vincent Danen 2011-07-01 04:52:48 UTC
Created PackageKit tracking bugs for this issue

Affects: fedora-15 [bug 718127]
Affects: fedora-rawhide [bug 718128]

Comment 21 Richard Hughes 2011-07-01 08:41:54 UTC
Created attachment 510816 [details]
Upstream fix

Comment 23 Peter Robinson 2012-03-14 11:27:20 UTC
I believe all affected releases are fixed

Comment 25 Tomas Hoger 2012-03-27 12:41:31 UTC
(In reply to comment #23)
> I believe all affected releases are fixed

This is still to be fixed in a future RHEL-6 minor release.

Comment 26 Peter Robinson 2013-02-05 15:08:44 UTC
(In reply to comment #25)
> (In reply to comment #23)
> > I believe all affected releases are fixed
> 
> This is still to be fixed in a future RHEL-6 minor release.

Is it fixed yet?

Comment 27 Vincent Danen 2013-02-05 22:20:18 UTC
As of yet, no, this is not yet fixed.  However, keep in mind that this is a low impact issue, so the priority is always on the more severe issues that require fixing.


Note You need to log in before you can comment on or make changes to this bug.