Bugzilla – Bug 852368
VUL-0: CVE-2013-6402: hplip: arbitrary file creation/overwrite (via hardcoded file name /tmp/hp-pkservice.log)
Last modified: 2019-05-01 16:07:55 UTC
hplip once again creates logfiles in /tmp, which allows local users to create/overwrite arbitrary files. Thats here in base/pkit.py class BackendService(PolicyKitService): INTERFACE_NAME = 'com.hp.hplip' SERVICE_NAME = 'com.hp.hplip' LOGFILE_NAME = '/tmp/hp-pkservice.log' [...] Best fix would be for hplip to use the standard syslog facility, relying on syslogd, rather than creating logfiles in /tmp.
Sebastian Krahmer, do you get a new CVE number for this new issue? For the log: This was the previous issue regarding /tmp files: bnc#808355 - VUL-1: CVE-2013-0200: hplip*: local file overwrite via /tmp files
I think we will. Either via upstream or vis oss-sec. I'll just mail upstream about this, so they can fix.
Public, as via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725876
ping?
Was reported upstream by me, we are waiting for them.
(In reply to comment #5) > Was reported upstream by me, we are waiting for them. Hmmmm, can't see it here: https://bugs.launchpad.net/hplip/+cve or when searching for this CVE through all the hplip bugs: https://bugs.launchpad.net/hplip?field.searchtext=CVE-2013-6402&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package= How did you report it upstream?
Seems to got CVE-2013-6402 meanwhile. Reported on Date: Thu, 5 Dec 2013 to HP developers, taking our sec-team members and maintainer in Cc. As there are a lot of queued hplip issues, I dont know how to handle it. I agree with Johannes that we cannot make hplip updates every week. Check https://bugzilla.novell.com/show_bug.cgi?id=853405
(In reply to comment #7) > > Check https://bugzilla.novell.com/show_bug.cgi?id=853405 Well, that's pretty easy to fix, do as Fedora or as we (Mageia) did and remove all of the upgrader, binary and .py files as it should never be run when using distro packages. But I get your point about the overall hplip situation, totally comprehensible. FWIW, here's a fix in the meantime for this CVE: https://bugs.mageia.org/attachment.cgi?id=4714&action=diff But just did a quick scan for similiar issues (grep -Ri for logfile and log_file) and at least this shows up: ./prnt/hpijs/foomatic-rip-hplip:my $logfile = "/tmp/foomatic-rip";
I added the HPLIP upstream developer Amarnath Chitumalla to the CC list of this bug to keep HPLIP upstream directly informed. Florian Hubold, FYI regarding "foomatic-rip-hplip" in your comment#8: Fortunately we (i.e. openSUSE) do no longer distribute this file since some time because - guess what! - one more security issue (inherited from foomatic-rip), see our hplip RPM changelog file at https://build.opensuse.org/package/view_file/Printing/hplip/hplip.changes?expand=1 that reads in particular: -------------------------------------------------------------------- Fri Aug 12 10:36:13 CEST 2011 - jsmeix@suse.de ... - Because foomatic-rip-hplip has CVE-2011-2697 (bnc#698451) plus a leftover in CVE-2004-0801 (bnc#59233) foomatic-rip-hplip is no longer installed and foomatic-rip from the foomatic-filters RPM is used instead and the "cupsFilter" entries in the PPDs are changed accordingly. To be backward compatible with PPDs in /etc/cups/ppd/ for existing print queues a compatibility link /usr/lib/cups/filter/foomatic-rip-hplip which points to foomatic-rip is installed. --------------------------------------------------------------------
Johannes, I would vote for a solution like in comment#8: "move all of the upgrader, binary and .py files as it should never be run when using distro packages." So we can get rid of code that violates our policy anyways, like autoupdating by dling a tarball etc.
(In reply to comment #10) > Johannes, I would vote for a solution like in comment#8: > > "move all of the upgrader, binary and .py files as it should never be run when > using distro packages." > > So we can get rid of code that violates our policy anyways, > like autoupdating by dling a tarball etc. FWIW you missed two letters - but you can also move the files to /dev/null :p That's what we do: http://svnweb.mageia.org/packages/cauldron/hplip/current/SPECS/hplip.spec?view=markup 460 # remove all upgrade-dialog files, also related to CVE-2013-6427 461 # previously we only removed the upgrade binary, but missed some upgrade dialog files 462 rm -f %{buildroot}%{_datadir}/hplip/upgrade* 463 rm -f %{buildroot}%{_bindir}/hp-upgrade
Florian Hubold, isn't your above comment#11 actually meant for bnc#853405 because that one is about hp-upgrade? Sebastian Krahmer, regarding the issue in this bug here I also think a patch as in https://bugs.mageia.org/attachment.cgi?id=4714&action=diff would be the right solution here. I will do it when time permits, compare https://bugzilla.novell.com/show_bug.cgi?id=853405#c5 https://bugzilla.novell.com/show_bug.cgi?id=853405#c17 From my point of view for me it is currently more important to get the currently somewhat broken printing stuff in openSUSE:Factory working again. From my point of view I would like to care first and foremost about to keep the base printing stuff working in general. But when management decides, I could leave the base printing stuff somewhat broken in openSUSE:Factory and work first and foremost on this HPLIP security issue.
Or should I work first and foremost on bnc#858462?
Or is bnc#857372 of topmost importance?
I am working on bnc#857372 now (also P3 but I think CUPS is more important than HPLIP so that this bug here must wait).
I am working on this one now (together with bnc#853405).
Submitted as maintenancerequest 213968 The issue is now fixed. I re-assign it to the Bugzilla default assignee for further processing.
This is an autogenerated message for OBS integration: This bug (852368) was mentioned in https://build.opensuse.org/request/show/213968 13.1+12.2+12.3 / hplip
openSUSE-SU-2014:0127-1: An update that fixes two vulnerabilities is now available. Category: security (moderate) Bug References: 852368,853405 CVE References: CVE-2013-6402,CVE-2013-6427 Sources used: openSUSE 13.1 (src): hplip-3.13.10-4.2 openSUSE 12.3 (src): hplip-3.12.11-2.9.2 openSUSE 12.2 (src): hplip-3.12.4-3.10.1
openSUSE-SU-2014:0146-1: An update that fixes one vulnerability is now available. Category: security (moderate) Bug References: 852368 CVE References: CVE-2013-6402 Sources used: openSUSE 11.4 (src): hplip-3.11.5-1.19.1
Update released for: hplip, hplip-debuginfo, hplip-debugsource, hplip-hpijs Products: SLE-DEBUGINFO 11-SP2 (i386, ia64, ppc64, s390x, x86_64) SLE-DESKTOP 11-SP2 (i386, x86_64) SLE-SERVER 11-SP2 (i386, ia64, ppc64, s390x, x86_64) SLES4VMWARE 11-SP2 (i386, x86_64)
SUSE-SU-2014:0188-1: An update that solves three vulnerabilities and has one errata is now available. Category: security (moderate) Bug References: 808355,835827,836937,852368 CVE References: CVE-2013-0200,CVE-2013-4325,CVE-2013-6402 Sources used: SUSE Linux Enterprise Server 11 SP2 for VMware (src): hplip-3.11.10-0.6.11.1 SUSE Linux Enterprise Server 11 SP2 (src): hplip-3.11.10-0.6.11.1 SUSE Linux Enterprise Desktop 11 SP2 (src): hplip-3.11.10-0.6.11.1
SUSE-SU-2014:0188-2: An update that solves three vulnerabilities and has one errata is now available. Category: security (moderate) Bug References: 808355,835827,836937,852368 CVE References: CVE-2013-0200,CVE-2013-4325,CVE-2013-6402 Sources used: SUSE Linux Enterprise Server 11 SP3 for VMware (src): hplip-3.11.10-0.6.11.1 SUSE Linux Enterprise Server 11 SP3 (src): hplip-3.11.10-0.6.11.1 SUSE Linux Enterprise Desktop 11 SP3 (src): hplip-3.11.10-0.6.11.1
polkit not in sle10, so this code is not active there I think
Affected packages: SLE-11-SP3: hplip SLE-10-SP3-TERADATA: hplip SLE-11-SP2: hplip