Insecure binary driver verification (CVE-2015-0839)

Bug #1432516 reported by Enrico Zini on 2015-03-16
256
This bug affects 1 person
Affects Status Importance Assigned to Milestone
HPLIP
Undecided
Unassigned

Bug Description

Hello,

I was forced to run hp-plugin to download a binary driver for the new printer, and I noticed this bit:

  Downloading plug-in from:
  Receiving digital keys: /usr/bin/gpg --homedir /home/enrico/.hplip/.gnupg --no-permission-warning --keyserver pgp.mit.edu --recv-keys 0xA59047B9
  Creating directory plugin_tmp
  Verifying archive integrity... All good.

The use of a short key ID worries me, because it is now trivial to generate keys with arbitrary key IDs, and gpg --recv-keys will happily download all those it finds. Also, pgp.mit.edu is a keyserver where everyone can upload arbitrary keys.

You can run "gpg --recv 70096AD1" to play with multiple keys having the same key ID.

I assume hp-plugin is open to downloading and verifying plugins signed by any key that one can verify that have that short key ID, and that with that and some fiddling with DNS one can cause systems running hp-plugin to download and run malicious code.

A quick fix would be to use the full fingerprint instead of the key id.

I'm reporting the bug here on request by the Debian Security team.

Thank you,

Enrico

CVE References

Johannes Meixner (jsmeix) wrote :

Our SUSE security team informed me about that issue.

Meanwhile the issue was reported 11 weeks ago and
up to now there is no response from HPLIP upstream.

This proves that HPLIP upstream is not really interested
in solving security issues sufficiently.

In the past there have been varios security issues in HPLIP.
The HPLIP software is full of various kind of security issues.

I do not have the time to continuously fix security bug after
security bug after security bug in a software where upstream
introduces security issue after security issue after security issue
and where upstream introduces functionality that is "by design"
a security issue for a Linux distributor - at least for SUSE.

The only thing what I am willing to do here is to disable the whole
hp-plugin proprietary driver download functionality in HPLIP
like I had already disabled the whole hp-upgrade functionality.

The root of this issue is the same as it was for the
hp-upgrade functionality:

HPLIP downloads and installs software onto a user's system
that is not from the Linux distributor (i.e. third-party software).

The hp-upgrade functionality downloads and installs
a whole HPLIP upgrade, the hp-plugin functionality
downloads and installs proprietary driver/firmware.

This behaviour is a generic security issue for a Linux distributor
who provides maintenance (in particular security updates)
for his users.

I have alredy explained that, see my
"Explanation why I cannot run hp-config_usb_printer via udev:" in
https://bugs.launchpad.net/hplip/+bug/1220628/comments/18

Accordingly it seems I must disable the whole hp-plugin proprietary
driver/firmware download functionality in HPLIP for SUSE.

As a positive side-effect users who use HPLIP from SUSE
would be no longer affected by the gpg key issue here.

It could be seen as a negative consequence when then
HPLIP from SUSE does no longer support that
weak cheap printers that need proprietary stuff.

From my point of view as HPLIP package maintainer at SUSE
this is even also a positive consequence because then
users with such printers must actively download and
install HPLIP directly from HP and then issues with HPLIP
for such printers do no longer bother me but only HP.

Of course normal printers "just work" with free software
including the free parts of HPLIP that SUSE provides.

Johannes Meixner (jsmeix) wrote :

After 2 more weeks (so that it is now 11 weeks)
without any response from HPLIP upstream
I still hope HPLIP upstream might finally get
a tiny bit of interest in solving their security issues.

From our (SUSE) security experts I got the following
suggested patch against the latest HPLIP 3.15.6:
==============================================================
--- hplip-3.15.6/base/validation.py
+++ hplip-3.15.6/base/validation.py
@@ -42,7 +42,7 @@ class DigiSign_Verification(object):

 class GPG_Verification(DigiSign_Verification):
- def __init__(self, pgp_site = 'pgp.mit.edu', key = 0xA59047B9):
+ def __init__(self, pgp_site = 'pgp.mit.edu', key = 0x73D770CDA59047B9):
         self.__pgp_site = pgp_site
         self.__key = key
         self.__gpg = utils.which('gpg',True)
==============================================================
This should address this particular vulnerability (only).
Basically, use 0xlong key ID, short of shipping the key
or full fingerprint.

Johannes Meixner (jsmeix) wrote :

Typo correction:
it is now _13_ weeks without any response from HPLIP upstream.

Johannes Meixner (jsmeix) wrote :

FWIW:

Also our (SUSE) security team imformed me that
the real solution would be when the HPLIP software
contains the complete public fingerprint and uses that
instead of the key id.

On Fri, Jun 19, 2015 at 02:19:58PM -0000, Johannes Meixner wrote:

> Also our (SUSE) security team imformed me that
> the real solution would be when the HPLIP software
> contains the complete public fingerprint and uses that
> instead of the key id.

The Debian maintainer of gnupg is worried that the complete public
fingerprint may not be enough, and suggests instead to ship the whole
public key with HPLIP, which I think is a good idea, and would even skip
the whole keyserver step entirely.

I wonder why that wasn't done in the first place.

Enrico

--
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <email address hidden>

Johannes Meixner (jsmeix) wrote :

Yes.
The whole public key needs to be included in HPLIP.
This is also what our (SUSE) security team had
actually told me.

Unfortunately in my previous comment I confused
"the whole public key" with "the complete public fingerprint".

For clarification some more details:

Our (SUSE) security team suggests that HPLIP has
the whole public key included so that no longer
any key needs to be downloaded at all.

This way the chain of trust in HPLIP would be the same
as for other software (cf. Mozilla Firefox that has
certificates included which are similar to keys).

In this case the chain of trust is that the Linux distribution
ensures to get the right sources from upstream that contain
the right keys so that the Linux distributor builds binaries
with the right keys included so that finally the users of the
Linux distribution use the right keys on their systems.

This way the users of a Linux distribution need to trust
only their distribution (which they need to trust anyway)
but not some possibly obscure other parties that the
users may not clearly know in advance - e.g. whatever
web-site wherefrom whatever stuff (e.g. binaries, keys,...)
gets downloaded, installed and used on their systems.

Including the whole public key in HPLIP only solves this
particular issue. It does not solve the general issue that
by using HPLIP third-party software (proprietary plugins)
may get downloaded, installed and run on user's systems
(when users have printers that require it).

Suma Byrappa (suma-byrappa) wrote :

Hello,

In the new release of HPLIP, 3.15.7, we have changed the verification to be based on fingerprint instead of key id. This is an interim solution. We are working on a final solution which should be available in an upcoming release. This bug will be marked "Fix Released" when the final solution will be made available.

Regards,
Suma

Enrico Zini (enrico) wrote :

Since the issue has been publicly disclosed (http://seclists.org/oss-sec/2015/q2/581) can you please mark this bug "non-private"?

Enrico Zini (enrico) wrote :

Never mind, I found the option to do that.

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

Other bug subscribers