A CVE has been assigned for a security issue in hplip (insecure tmp file): http://www.openwall.com/lists/oss-security/2013/11/28/3 Other references for this issue from that thread: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725876 https://bugzilla.novell.com/show_bug.cgi?id=852368 Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA3TOO
Blocks: (none) => 11726
No patch available yet. Flagged invalid for RHEL 5/6: https://bugzilla.redhat.com/show_bug.cgi?id=1035243#c4 Will look at it when looking at CVE-2013-4325 as per https://security-tracker.debian.org/tracker/source-package/hplip (which was fixed with 3.13.10)
Status: NEW => ASSIGNEDCC: (none) => doktor5000
Thanks Florian.
Summary: hplilp new security issue CVE-2013-6402 => hplip new security issues CVE-2013-4325 and CVE-2013-6402
There's also CVE-2013-6427, discussed in this thread: http://openwall.com/lists/oss-security/2013/12/05/1 We don't have an upgrade.py in our Mageia 3 package (although there are other upgrade_*.py files), so maybe we've already removed it, so I'm guessing we're not affected, but just bringing it up to be sure. Slackware had to issue an advisory for this: http://lwn.net/Vulnerabilities/576002/
We shouldn't have that, as it would enable end-user to upgrade hplip, which must be avoided when using distribution packages. This was imported from Fedora. http://svnweb.mageia.org/packages/cauldron/hplip/current/SPECS/hplip.spec?view=markup 453 rm -f %{buildroot}%{_datadir}/hplip/upgrade.* 454 rm -f %{buildroot}%{_bindir}/hp-upgrade But seems that's too lax, probably need to readjust. Will check with current Cauldron. FWIW, checked the files via for i in $(urpmf -f --name hplip); do urpmq -l $i | grep upgrade; done and found some like /usr/share/hplip/ui4/upgradedialog*
Okay, current state: CVE-2013-4325 was fixed by colin already: http://svnweb.mageia.org/packages?view=revision&revision=483257 For CVE-2013-6427 I've removed the rest of the upgrade files, but we're probably not vulnerable there, as we don't ship the upgrade binary. For CVE-2013-6402 I've not seen a patch somewhere, even though Debian has raised severity to Serious for that one. If somebody knows a bit about python, would be nice to create a patch to replace the hardcoded file in /tmp with this: http://docs.python.org/2/library/tempfile.html#tempfile.mkstemp
Summary: hplip new security issues CVE-2013-4325 and CVE-2013-6402 => hplip new security issue CVE-2013-6402
Created attachment 4687 [details] hplip-3.13.9-mga-CVE-2013-6402.patch This part of code is used only when policykit is enabled Since it is a log file I'm not sure that using tempfile.mkstemp is the best solution, and later in the code the logfile is renamed by adding the pid. But if you want a quick patch I hope you can use this one hplip-3.13.9-mga-CVE-2013-6402.patch
CC: (none) => makowski.mageia
Attachment 4687 is obsolete: 0 => 1
Created attachment 4688 [details] hplip-3.13.9-mga-CVE-2013-6402.patch correct version
(In reply to Philippe Makowski from comment #7) > Created attachment 4688 [details] > hplip-3.13.9-mga-CVE-2013-6402.patch Well, I'm not sure. In line #205 it already connects to udev, and uses the hardcoded LOGFILE_NAME. This is why I'd prefer to use the previous patch. Apart from that, from the linked python docs: "Unlike TemporaryFile(), the user of mkstemp() is responsible for deleting the temporary file when done with it." also (probably irrelevant, but should be considered) "The file is readable and writable only by the creating user ID" I'll apply the patch and push to updates_testing, but I've not much means to check since I don't have a printer. Luigi, could you try this out?
yes a better fix would be to either don't enable policykit, either do a larger patch to use the standard syslog facility, relying on syslogd, rather than creating logfiles in /tmp. but this small one can work I hope
Okay, after some basic testing, simply running hp-plugin as normal user creates the logfile. Before: ls -ltr /tmp [...] -rw-r----- 1 root root 0 Jan 4 17:39 hp-pkservice.log.10541 ^^^^ looks strange, as I've started it as normal user ... After applying the previous patch it seems no logfile is generated. So security issue is fixed, but logfile doesn't get written anymore :/ Even when we fix this, the logfile would be persistent and would need to be removed too. Any ideas? I'd say wait for the fix from upstream.
(In reply to Philippe Makowski from comment #9) > yes a better fix would be to either don't enable policykit, Ok, but how do you handle granting permissions then? > either do a larger patch to use the standard syslog facility, > relying on syslogd, rather than creating logfiles in /tmp. It seems this log is intended for debug purposes only (look at the loglevel). If you have a patch to let it write to syslog, just shoot. Looking at http://docs.python.org/2/library/syslog.html pkit.py looks like quite some work.
(In reply to Florian Hubold from comment #11) > (In reply to Philippe Makowski from comment #9) > > yes a better fix would be to either don't enable policykit, > > Ok, but how do you handle granting permissions then? I don't know enough hplip to reply, but I saw that Fedora for example don't enable it > > either do a larger patch to use the standard syslog facility, > > relying on syslogd, rather than creating logfiles in /tmp. > > It seems this log is intended for debug purposes only (look at the > loglevel). If you have a patch to let it write to syslog, just shoot. > > Looking at http://docs.python.org/2/library/syslog.html pkit.py looks like > quite some work. yes :(
Here what I have : before : launch as root python /usr/bin/hp-pkservice -i -g run as simple user hp-plugin try to install plugin, it fail, you get "error: Plug-in install failed." hp-pkservice stop and you have in /tmp/hp-pkservice.log.xxx (where xxx is the pid of hp-pkservice) the error and a message "debug: stopping backed service" perms are -rw-r----- 1 root root after (with a new patch) launch as root python /usr/bin/hp-pkservice -i -g run as simple user hp-plugin try to install plugin, it fail, you get "error: Plug-in install failed." hp-pkservice stop and you have in /tmp/tmpxxxxx (where xxx is random) the error and a message "debug: stopping backed service" perms are -rw------- 1 root root is that acceptable ? the name of the temp file use the default prefix "tmp" as indicated here http://docs.python.org/2/library/tempfile.html#tempfile.mkstemp but I can remove the prefix if need so it will be a random name.
(In reply to Florian Hubold from comment #10) > Okay, after some basic testing, simply running hp-plugin as normal user > creates the logfile. > > Before: > > ls -ltr /tmp > [...] > -rw-r----- 1 root root 0 Jan 4 17:39 hp-pkservice.log.10541 > > ^^^^ looks strange, as I've started it as normal user ... the code in /usr/share/hplip/pkservice.py take care of this, pkservice.py is run as root and can't be run by someone else than root
Created attachment 4714 [details] new patch for cve-2013-6402 new patch with log file without prefix, to get a completly random name and a file owned by root and only readable and writable by root. hope it is acceptable enough.
Attachment 4688 is obsolete: 0 => 1
(In reply to Philippe Makowski from comment #12) > (In reply to Florian Hubold from comment #11) > > (In reply to Philippe Makowski from comment #9) > > > yes a better fix would be to either don't enable policykit, > > > > Ok, but how do you handle granting permissions then? > I don't know enough hplip to reply, but I saw that Fedora for example don't > enable it Well, they disable it, but still shop some parts of it: http://pkgs.fedoraproject.org/cgit/hplip.git/tree/hplip.spec#n958 and the changelog entry below And they also seem to be affected by the previous CVE-2013-4325: http://pkgs.fedoraproject.org/cgit/hplip.git/tree/hplip.spec#n487 Anyways, your results sound good, but what about the deletion of the logfile? Do we just keep it there? Seems the original code also doesn't remove the logfile afterwards, so may be OK. Luigi, what do you think? BTW: Next tentative release date from upstream should be January 14, fix for this may be contained, but that would be 3 version updates. Not sure if that's OK for release freeze, probably not.
(In reply to Florian Hubold from comment #16) > Anyways, your results sound good, but what about the deletion of the > logfile? Do we just keep it there? Seems the original code also doesn't > remove the logfile afterwards, so may be OK. yes the original code doesn't remove it If you agree, apply my last patch to solve now the issue and I will try to find time to write another that will write to syslog instead, or wait for the next upstream to see if they fix it and if it can be back ported.
Created attachment 4727 [details] CVE-2013-6402-deb.patch I found the Debian Patch the solution is not far from mine, but simpler as it generate a file in /tmp with a name hp-pkservice-xxxx.log.yyyy where xxxx is random and yyy is the pid like in upstream code. Debian use tempfile.mktemp, but this is deprecated, the Python doc clearly say : "Deprecated since version 2.3: Use mkstemp() instead." so you have choice.
Submitted hplip-3.13.9-3.mga4 to updates_testing. I've used the previous patch which uses tempfile.mkstemp. Also removes the remaining upgrade dialog files related to CVE-2013-6427, as mentioned in https://bugs.mageia.org/show_bug.cgi?id=11809#c5 And I've added a Requires on usbutils, as it seems necessary for hp-check. Please test, if results are OK will also push that to mga3.
CC'ing the QA team if anyone is interested in helping test this in Cauldron before it's pushed to Mageia 3.
CC: (none) => qa-bugs
We usually ask for testing on discuss ml for hplip. Might be worth CC'ing previous testers.
Ubuntu has issued an advisory for this today (January 21): http://www.ubuntu.com/usn/usn-2085-1/
URL: (none) => http://lwn.net/Vulnerabilities/581564/
Well, they completely remove the logfile with their patch: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/hplip/quantal-security/view/head:/debian/patches/CVE-2013-6402.patch @David: What do you think, shall we better use this approach then securing the logfile, which only seems to be for debugging purposes?
Ahh, they backported it from the upstream fix: http://hplipopensource.com/hplip-web/release_notes.html So I'll use this one, and will also apply it for mga3, after I went through all the changes in between :/
Updated package sent to updates_testing, will take a look at mga3.
@David: Do you prefer a separate bug for the mga3 update? hplip-3.12.9-6.3.mga3 has just been sent to updates_testing. Suggested advisory: Updated hplip packages fix security vulnerabilities: It was discovered that the HPLIP Polkit daemon incorrectly handled temporary files. A local attacker could possibly use this issue to overwrite arbitrary files. (CVE-2013-6402) It was discovered that HPLIP contained an upgrade tool that would download code in an unsafe fashion. If a remote attacker were able to perform a man-in-the-middle attack, this flaw could be exploited to execute arbitrary code. (CVE-2013-6427) References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6402 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6427 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725876
Assignee: doktor5000 => qa-bugs
Florian, I thought we had determined that we weren't vulnerable to CVE-2013-6427, even if you did end up removing some additional files from the distro. If that's correct, it shouldn't be included in the advisory. We don't need a separate bug, but this will need pushed in Cauldron before it's pushed for Mageia 3 (so a freeze push request needs sent to the dev ml). I'll leave it blocking the tracker until it's pushed there. Only other thing is I'd add the Ubuntu advisory to the references.
Version: Cauldron => 3Whiteboard: MGA3TOO => (none)
Well, basically we are also vulnerable, if some parts of hplip don't invoke the binary but the python scripts directly, hence all other distros have also removed all upgrade-related files. And for CVE-2013-6427 no previous advisory has been issued, so why not? Better be safe then sorry ... Freeze push for cauldron has been sent. And feel free to enhance the advisory :)
Thanks for the clarification on CVE-2013-6427. Other than adding the Ubuntu advisory URL, the advisory should be good.
Can you remember to list RPM's too please Florian, thanks. Pasting from madb.. *** Arch: i586 *** RPMs from 'core-updates_testing' ======================== hplip-3.12.9-6.3.mga3.i586.rpm hplip-doc-3.12.9-6.3.mga3.i586.rpm hplip-gui-3.12.9-6.3.mga3.i586.rpm hplip-hpijs-3.12.9-6.3.mga3.i586.rpm hplip-hpijs-ppds-3.12.9-6.3.mga3.i586.rpm hplip-model-data-3.12.9-6.3.mga3.i586.rpm libhpip0-3.12.9-6.3.mga3.i586.rpm libhpip0-devel-3.12.9-6.3.mga3.i586.rpm libsane-hpaio1-3.12.9-6.3.mga3.i586.rpm SRPMs from 'core-updates_testing' ======================== hplip-3.12.9-6.3.mga3.src.rpm *** Arch: x86_64 *** RPMs from 'core-updates_testing' ======================== hplip-3.12.9-6.3.mga3.x86_64.rpm hplip-doc-3.12.9-6.3.mga3.x86_64.rpm hplip-gui-3.12.9-6.3.mga3.x86_64.rpm hplip-hpijs-3.12.9-6.3.mga3.x86_64.rpm hplip-hpijs-ppds-3.12.9-6.3.mga3.x86_64.rpm hplip-model-data-3.12.9-6.3.mga3.x86_64.rpm lib64hpip0-3.12.9-6.3.mga3.x86_64.rpm lib64hpip0-devel-3.12.9-6.3.mga3.x86_64.rpm lib64sane-hpaio1-3.12.9-6.3.mga3.x86_64.rpm SRPMs from 'core-updates_testing' ======================== hplip-3.12.9-6.3.mga3.src.rpm
Cauldron shows as being in updates_testing too, is that intended? SRPMs from 'core-updates_testing' ======================== hplip-3.13.9-4.mga4.src.rpm
Yes he originally pushed it to updates_testing in Cauldron to test it there, and then asked for a freeze push to get it built in core/release.
Tested mga3-32. Scanned an image to xsane viewer, printed a document, all OK. Started the scripts as mentioned above, did not note the creation of the hp-pkservice log. Did not run the download script past the initial window, as working ppds are downloaded as part of the package. Scanner: Hp scanjet 5p Printer HP laserjet 6L
CC: (none) => wrw105
Whiteboard: (none) => mga3-32-ok
Testing mga3-64, Testing complete for hplip-3.12.9-6.3.mga3, ok for me and nothing to report. -Printed a document -scanned a document with xsane -Installed plugin as a simple user (console and graphical) -Printer sharing with Samba --------------------------------------------------------------------------- $ hp-plugin HP Linux Imaging and Printing System (ver. 3.12.9) Plugin Download and Install Utility ver. 2.1 Copyright (c) 2001-14 Hewlett-Packard Development Company, LP This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to distribute it under certain conditions. See COPYING file for more details. \Checking for network connection... Downloading configuration file from: http://hplip.sf.net/plugin.conf Checking for network connection... Downloading plug-in from: http://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/hplip-3.12.9-plugin.run Receiving digital keys: /usr/bin/gpg --no-permission-warning --keyserver pgp.mit.edu --recv-keys 0xA59047B9 Verifying archive integrity... All good. Uncompressing HPLIP 3.12.9 Plugin Self Extracting Archive..................................................... HP Linux Imaging and Printing System (ver. 3.12.9) Plugin Installer ver. 3.0 Copyright (c) 2001-14 Hewlett-Packard Development Company, LP This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to distribute it under certain conditions. See COPYING file for more details. Plug-in version: 3.12.9 Installed HPLIP version: 3.12.9 Number of files to install: 48 Done. Plug-in installation successful. Done.
CC: (none) => geiger.david68210Whiteboard: mga3-32-ok => mga3-32-ok mga3-64-ok
(In reply to claire robinson from comment #30) > Can you remember to list RPM's too please Florian, thanks. Sorry /o\ Will do next time :)
hplip-3.13.9-4.mga4 uploaded for Cauldron.
Blocks: 11726 => (none)
Depends on: (none) => 10067
Advisory merged with bug 10067 and uploaded: type: sec subject: Updated hplip package fixes security vulnerabilities src: 3: core: - hplip-3.12.9-6.3.mga3 description: | It was discovered that the HPLIP Polkit daemon incorrectly handled temporary files. A local attacker could possibly use this issue to overwrite arbitrary files. (CVE-2013-6402) It was discovered that HPLIP contained an upgrade tool that would download code in an unsafe fashion. If a remote attacker were able to perform a man-in-the-middle attack, this flaw could be exploited to execute arbitrary code. (CVE-2013-6427) Additionnally, this update fixes wireless connection to printer issues: hplip after 3.12.9 and prior to version 3.12.11 had issues with setting up wireless connection to printers due to internal code changes which had not been applied consistently. This update adresses this issue. references: - https://bugs.mageia.org/show_bug.cgi?id=11809 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6402 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6427 - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725876 - https://bugs.launchpad.net/hplip/+bug/1048754 Now we need to either check the wireless connection to printers OR remove them from the advisory (including the last link in references) and push this validated sec update.
CC: (none) => stormiWhiteboard: mga3-32-ok mga3-64-ok => mga3-32-ok mga3-64-ok advisory
Depends on: 10067 => (none)
I rephrased the advisory (added "should") regarding the wireless issue since no one tested it and we need to push the update. Update validated, advisory in SVN. Please sysadmins push it to 3/core/updates.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
CC: makowski.mageia => (none)
Update pushed: http://advisories.mageia.org/MGASA-2014-0033.html
Status: ASSIGNED => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED