Insecure binary driver verification (CVE-2015-0839)

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.

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.

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

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>

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

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

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

Never mind, I found the option to do that.