On Fri, Nov 17, 2023 at 10:37:04AM +0100, Matthias Gerstner wrote: There is currently no upstream fix available for this issue and this publication happens after 90 days of attempted coordinated disclosure, but upstream did not react to my report. I was just informed that upstream release 3.23.12 released on 2023-11-30 silently fixes this issue. The fix is based on the patch that I posted on this list.
Best Regards
Matthias
Hello Alex,
On Thu, Nov 30, 2023 at 10:28:55AM +1030, Alex Murray wrote: I just wanted to follow-up on this to see if a CVE was ever assigned? I did not get any news neither in the private Launchpad issue for the hplip project, nor after contacting hp-security-alert () hp com, as was suggested by others in this thread.
Best Regards
Matthias
Hi Matthias
I just wanted to follow-up on this to see if a CVE was ever assigned?
Thanks, Alex
On Mon, 2023-11-20 at 14:39:02 +0100, Matthias Gerstner wrote: Hi,
thank you both for your suggestions. I just reached out to hp-security-alert () hp com about this.
There are a couple of other hplip issues I know of that have also been left unattended for a long time that I mentioned there as well.
Best Regards
Matthias
On Sun, Nov 19, 2023 at 07:11:37AM -0500, Mike O'Connor wrote: [removing security () hpe com from the Cc:]
This is for hp.com product security, not hpe.com. HP and HPE are two separate companies, and HPE isn't the printer company.
To report a potential security vulnerability with a HP product, contact: hp-security-alert () hp com
Both HPE and HP are CVE CNAs. Here's HP's CVE CNA information: https://www.cve.org/PartnerInformation/ListofPartners/partner/hp
HTH, -Mike
:Thanks for making the community aware of this issue. : :Perhaps security () hpe com can help to route internally to get a CVE issued :and find the appropriate owners to fix.
It was reported that the hp-plugin utility, included in the hplip package, downloads a binary driver and verifies it via a key specified by the key's short ID:
Downloading plug-in: [\ ] 0% Receiving digital keys: /bin/gpg --homedir /home/test/.hplip/.gnupg --no-permission-warning --keyserver pgp.mit.edu --recv-keys 0xA59047B9
A man-in-the-middle attacker could use this flaw to generate a key with the expected short ID and trick a user into downloading a malicious binary.
Original report:
http://seclists.org/oss-sec/2015/q2/581
Sebastian Krahmer reported a security issue was found in polkit (CVE-2013-4288 bz 1002375).
It was found that hplip was vulnerable to this issue as well, since it communicated to polkit authority using an unsafe DBUS interface.
This issue has been assigned CVE-2013-4325
Sebastian Krahmer reported a flaw in how hplip discovered SNMP devices. If certain hplip commands were run that queried SNMP devices, and a malicious user were able to send crafted SNMP responses, it could cause the running hplip tool to crash or, possibly, execute arbitrary code with the privileges of the user running the tool.
Acknowledgements:
Red Hat would like to thank Sebastian Krahmer of the SuSE Security Team for reporting this issue.
Kees Cook of the Ubuntu Security Team has informed us of following security vulnerability in hplip:
I just discovered that the hpssd daemon of hplip is vulnerable to arbitrary command injection via its use of popen3. Other local users can run commands as the invoker of hpssd (usually root, hplip, or a local user). By default, it only listens on localhost, but this is configurable via /etc/hp/hplip.conf, so in the worst-case it is possible this could allow remote root command execution.
Both 2.x and 1.x series appear vulnerable (but not 0.x which used SMTP).
The bug for this is: https://launchpad.net/bugs/149121