Bugzilla – Bug 933191
VUL-1: CVE-2015-0839: hplip: short key ID used when verifying binary printer driver downloads
Last modified: 2021-01-12 12:16:45 UTC
via oss-sec: http://seclists.org/oss-sec/2015/q2/581 > 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. From a security point of view, even long key IDs are better, but still not entirely sufficient way identify keys for *trust* relationships. The fingerprints or actual keys should be used. Rightly mentioned in http://seclists.org/oss-sec/2015/q2/596 : > A better quick fix would be to ship the authoritative key in hplip > directly, and avoid all interaction with the keyservers. Johannes, could you follow what upstream does here? Can you identify how this would affect us, how this could be solved in SUSE? References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-0839 http://seclists.org/oss-sec/2015/q2/581 http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-0839.html http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0839 https://bugs.launchpad.net/bugs/1432516
The root of this issue is the same as bug#853405 HPLIP can download and install non-SUSE software onto a user's system. In bug#853405 HPLIP can downloads and install a whole HPLIP upgrade, here HPLIP can downloads and install proprietary driver/firmware stuff. I have zero knowledge how that gpg keys work at all so that I cannot do a meaningful analysis here. For background information regarding security issues in general in HP's HPLIP software see https://bugzilla.suse.com/show_bug.cgi?id=853405#c5 The only thing what I am willing to do is to simply disable the whole hp-plugin proprietary driver download functionality in HPLIP just as I disabled the whole hp-upgrade functionality, cf. https://bugzilla.suse.com/show_bug.cgi?id=853405#c7 Perhaps only for SLE but not for openSUSE - just as you like. Only weak cheap crap printers need HP's proprietary driver plugin. Normal printers for normal (business) usage "just work" with our free software drivers (including the free parts of HPLIP) and never needed any proprietary stuff. Andreas Stieger, should I disable the proprietary stuff download in HPLIP? If yes, should I disable it for SLE and for openSUSE or only for SLE?
FYI regarding HPLIP can download and install non-SUSE software onto a user's system see "Explanation why I cannot run hp-config_usb_printer via udev:" at https://bugs.launchpad.net/hplip/+bug/1220628/comments/18 -------------------------------------------------------------------------- As far as I know hp-config_usb_printer can download and install proprietary software from HP (if needed for the printer device) or hp-config_usb_printer can trigger some other software that downloads and installs proprietary software from HP but SUSE policies do not allow to let any software be installed in any kind of (semi)-automated way - in particular no third-party software (regardless if it is free or proprietary software). As far as I know our SUSE policies, for any new software installation there must be an explicit request by root to install that software (an automated update of already installed software is different). -------------------------------------------------------------------------- When my reasoning there is valid, I must disable the proprietary stuff download in HPLIP for SLE and for openSUSE.
Regarding "what upstream does here": The upstream bug is https://bugs.launchpad.net/hplip/+bug/1432516 It 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.
Created attachment 638526 [details] suggested 3.15.6 patch Suggested patch against the latest 3.15.6
Created attachment 638527 [details] suggested 3.11.10 patch (SLE 11) This should address this particular vulnerability (only). Basically, use 0xlong key ID, short of shipping the key or full fingerprint.
Andreas Stieger, very many thanks for your suggested patches. I forwarded your suggested 3.15.6 patch to the HPLIP upstream bug https://bugs.launchpad.net/hplip/+bug/1432516 that exist now since 13 weeks without any response from HPLIP upstream.
According to the citation in comment#0 "A quick fix would be to use the full fingerprint instead of the key id." I informed HPLIP upstream in their bug https://bugs.launchpad.net/hplip/+bug/1432516 -------------------------------------------------------------------------- ... 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. --------------------------------------------------------------------------