Insecure binary driver verification (CVE-2015-0839)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
HPLIP |
New
|
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/
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
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 usb_printer via udev:" in /bugs.launchpad .net/hplip/ +bug/1220628/ comments/ 18
"Explanation why I cannot run hp-config_
https:/
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.