On 11 /var/run/cups/certs/0 can only be read by root / users of the sys group.
There are no users in this group on a vanilla SLE11. /etc/cups/cupsd.conf can
not be modified by other users than root -> unaffected. Applies to all SLE11.

On 10 it looks slightly different. While the key/s does not seem to be stored
in /var/run/cups/certs, the configuration *can* be modified. -> affected.

I would love to see cupsd running as non-root user. According to a posting on
Debian's BTS [2] it's possible, albeit with much efforts.

[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692791#31

Small addition:

(In reply to comment #1)
> On 11 /var/run/cups/certs/0 can only be read by root / users of the sys group.
> There are no users in this group on a vanilla SLE11. /etc/cups/cupsd.conf can
> not be modified by other users than root -> unaffected. Applies to all SLE11.
>

cupsd.conf could, however, of course be altered from the web interface since
the daemon runs as root. But the keys cannot be obtained easily.

> On 10 it looks slightly different. While the key/s does not seem to be stored
> in /var/run/cups/certs, the configuration *can* be modified. -> affected.

Can be modified by lp / people in the lp group.

Many thanks for this example how a user who is allowed to
change the cupsd configuration, is basically also allowed
to do anything in the system!

Regarding "Allow printer admin tasks for a normal user" see
http://en.opensuse.org/SDB:CUPS_in_a_Nutshell
I will enhance this section by this example.

I expected such an isssue all the time, compare
http://lists.opensuse.org/opensuse-factory/2012-05/msg00784.html
and now I have real example!


But - as far as I see - this is how CUPS works intentionally.
If we change how CUPS works intentionally we introduce regressions.
Before we "simply change" how CUPS works in our released business
products, we need to check very carefully if our changes actually
help our customers.

Note that by default in SLE11 only root (and in SLE10 root and lp)
is allowed to change the cupsd configuration (but in SLE10 cupsd
runs as lp so that cupsd cannot read e.g. /etc/shadow).
Only if a customer had intentionally manually allowed a normal user
to change the cupsd configuration (and in SLE10 if the customer
additionally manualy changed to let the cupsd run as root),
the issue happens.

I would like to know what CUPS upstream responds to
http://www.cups.org/str.php?L4223
but I am not allowed to access it.

Matthias Weckbecker,
do you or one of the security team have access to
http://www.cups.org/str.php?L4223
is you or one of the security team in contact
with upstream cups?


Regarding SLE11 and SLE10:

In SLE11 the cupsd runs as root.
Who is allowed to change the configuration how a root process runs
is basically allowed to do anything in the system.
The advantage to run cupsd as root is that root can switch user
and cupsd runs the filters/drivers of the printing system as lp
so that filters/drivers cannot change the cupsd config files.
In particular third party printer drivers cannot change the cupsd
(in theory - in practice third party printer drivers are usually
installed by root to that third party printer driver software
can do anything in the system at installation time).

In SLE10 we have "User lp, Group lp, RunAsUser Yes" in cupsd.conf
so that in SLE10 the cupsd runs as lp. See the section
"Configuration of the print queues on the server" at
http://en.opensuse.org/SDB:CUPS_in_a_Nutshell
This means that all files for the cupsd must have appropriate
permissions to access them as user lp. The drawback is that then
also the filters/drivers of the printing system run as the same user
as the cupsd runs (because lp cannot switch to another user)
so that filters/drivers can change the cupsd config files.
Comment #0 talks about "the web interface, where they can
edit the config file". If I remember correctly this is not possible
with the web interface of the old CUPS 1.1 version in SLE10.
I will check this...

Because in SLE10 the cupsd runs by default as lp it cannot
access arbitrary files so that from my point of view SLE10
is not affected by this issue.

Matthias Weckbecker,
do you agree that SLE10 is not affected?

(In reply to comment #5)
[...]
> 
> But - as far as I see - this is how CUPS works intentionally.
> If we change how CUPS works intentionally we introduce regressions.
> Before we "simply change" how CUPS works in our released business
> products, we need to check very carefully if our changes actually
> help our customers.

Sure.

> 
> Note that by default in SLE11 only root (and in SLE10 root and lp)
> is allowed to change the cupsd configuration (but in SLE10 cupsd
> runs as lp so that cupsd cannot read e.g. /etc/shadow).

I must have missed that. I thought cupsd runs as 'root' on SLE10 too, no?
Well, if it doesn't it won't be affecting cupsd by default.

Please note that on SLE10 it's lp:lp rather than root:lp. The latter is
present on SLE11.

[...]
> 
> Matthias Weckbecker,
> do you or one of the security team have access to
> http://www.cups.org/str.php?L4223
> is you or one of the security team in contact
> with upstream cups?
> 

No, sir.

> 
> Regarding SLE11 and SLE10:
> 
> In SLE11 the cupsd runs as root.
> Who is allowed to change the configuration how a root process runs
> is basically allowed to do anything in the system.
[...]

Yes and no. cupsd runs as 'root' on 11 and if you manage to log in to the
web interface (as any other user than 'root') it can become an issue.
See details from c#0 at [1], please.

[...]
> edit the config file". If I remember correctly this is not possible
> with the web interface of the old CUPS 1.1 version in SLE10.
> I will check this...

How come /etc/cups/cupsd.conf is lp:lp then on SLE10 at all?

> Because in SLE10 the cupsd runs by default as lp it cannot
> access arbitrary files so that from my point of view SLE10
> is not affected by this issue.
> 
> Matthias Weckbecker,
> do you agree that SLE10 is not affected?

Well, it depends. If one *can* edit the configuration file on SLE10 from
inside the web interface and other users can log in there, I won't agree.
Please keep in mind that we certainly support more than just the default
configuration. That's no excuse IMO.

Possible solutions:

To harden SLE11 some more (ie. prevent sys->root escalation) we could make the
key file(s) root:root 440. 

For SLE10 it looks (as expected) slightly different and depends on where cupsd
stores its key file(s) (and with which privs). If an administrator decides to
run cupsd as 'root' in order to enjoy additional features, we have to make sure the key(s) can also only be obtained by root.

Johannes, do you think this would make sense? What would you suggest?

For SLE11 it's simply a matter of setting 'SystemGroup' to 'root root'. Maybe
plus some warning if it's set to something too far-fetched.

I don't know what I should suggest right now.

But I know that in the past any attempt to make CUPS by default
more secure caused this or that complication that results
an endless discussion which always ended nowhere,
compare bnc#752454 (stuck in the middle of nowhere).

If we change for SLE11 the default "SystemGroup sys root"
to "SystemGroup root" (i.e. when we remove the group "sys")
it causes - strictly speaking - a regression and we may get
customer complaints why it does no longer work for "sys".

I need time to analyze and evaluate what could be done here.
Please be patient...

Created attachment 513297 [details]
For SLE10

(In reply to comment #9)
[...]
> 
> If we change for SLE11 the default "SystemGroup sys root"
> to "SystemGroup root" (i.e. when we remove the group "sys")
> it causes - strictly speaking - a regression and we may get
> customer complaints why it does no longer work for "sys".
> 

You are right. SystemGroup seems to be used for some other stuff as well, so
it will likely have unwanted side-effects in the end. Maybe some sort of the 
patch above could be used for 11 too.

As far as I currently understand the best description
of the root issue and probably the best way to fix it is
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692791#46
(excerpt)
-------------------------------------------------------------------------
From: Jeff Licquia <licquia@debian.org>
...
CUPS allows changes to the config file in two ways: changing a small
subset of settings in a way that's checked server-side, and editing
cupsd.conf in a browser by downloading the file, and then uploading the
edited version post-edit.  The latter functionality is what's being
exploited here, and it strikes me as far more dangerous than the former.

I've attached a proposed dpatch which disables just cupsd.conf editing.
...
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=46;filename=bug-692791.dpatch;att=1;bug=692791
-------------------------------------------------------------------------

In contrast the CUPS main author's opinion is
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692791#61
(excerpt)
-------------------------------------------------------------------------
From: Michael Sweet <msweet@apple.com>
...
As for a proposed fix, I'm thinking we will disable the log file,
RequestRoot, ServerRoot, and DocumentRoot directives in cupsd.conf,
and add command line arguments in their place. That will retain
configurability while eliminating this particular attack vector.
-------------------------------------------------------------------------

I have the gut feeling that editing the whole cupsd.conf file
via a web-interface will always be insecure regardless which
particular directives in cupsd.conf are removed (except basically
all directives in cupsd.conf would be removed to be really secure).

Therefore my personal opinion is that it is simple and secure
to remove the functionality to edit the whole cupsd.conf file
via the CUPS web-interface.

Removing this functionality is a regression but I believe
there is no SLE customer who uses that functionality and
even if customer uses that functionality, there is an
alternative via "ssh cups.server" and "vi cupsd.conf".

On the other hand - from my point of view - removing directives
in cupsd.conf and adding new command line arguments instead
looks an overcomplicated fix for a released CUPS version and
it causes a more severe regression because customers who use
non-default values for those directives would fall-back to the
defaults after the CUPS security update unless they know in
advance how to re-establish their non-default settings via
the new command line arguments.

Stefan,
the SWAMPID for this issue is 50084
with submit fixed packages until 2012-11-28
but that date has meanwhile passed.

The issue does not happen with our default settings,
see comment #5.

But with non-default settings the security issue exists.
To make the security issue impossible we would have to
remove functionality from CUPS but that causes regressions.

I cannot make a decision how to proceed here.

I would vote for lifting the deadline in this case. This is admittedly a rather
complex issue in many ways.

FYI,
the upstream bug report
http://www.cups.org/str.php?L4223
is meanwhile public accessible.

At a very first glance I think the upstream fix
is the right solution for the new CUPS version 1.6.

In contrast I think that for released CUPS versions,
in particular for our cups packages that run "since ages"
on our customers' systems, the upstream fix changes too much
to be provided by us as (mandatory?) security update.

I've negotiated with Marcus and he agreed on lifting the deadline.

I would like to provide a summary as far as I understand
the issue from my current point of view:

1. What the actual security issue is:

Users who are allowed to do CUPS admin tasks can change the
cupsd configuration (cupsd runs as root).
Because the cupsd configuration includes file locations
a CUPS admin can change in particular a log file location
to be an arbitrary file (e.g. /etc/shadow).
Furthermore cupsd provides the functionality to view the log files
so that a CUPS admin can leverage cupsd to view arbitrary files.

2. What to do against the security issue:

The basic idea is to disable editing file locations
for users who are allowed to do CUPS admin tasks
so that only root can change the file locations.

2a. The CUPS upstream solution:

Split the cupsd configuration into two parts, one part (still in
/etc/cups/cupsd.conf) for what can be changed by users who are
allowed to do CUPS admin tasks and another part (in the new file
/etc/cups/cups-files.conf) for what can only be changed by root.
In particular the file locations can only be changed by root.

2b. What could be done for released CUPS versions:

Initially the issue was reported how a CUPS admin can leverage
the CUPS web interface to view arbitrary files.
In this case it would have helped to disable certain
functionality (i.e. cupsd.conf editing) in the CGI program
that implements the functionality of the CUPS admin web
interface (i.e. cgi-bin/admin.c), see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692791#46

But this is insufficient because cupsd.conf editing is also
possible via /usr/sbin/cupsctl which means that for disabling
cupsd.conf editing one would need to disable HTTP PUT in cupsd, see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692791#126

As far as I understand it disabling cupsd.conf editing for CUPS admins
via CUPS web interface and /usr/sbin/cupsctl requires to remove
substantial functionality from CUPS and from my point of view
this is a too big regression for our released CUPS versions.

Also the split of the cupsd configuration into two files
/etc/cups/cupsd.conf and /etc/cups/cups-files.conf
causes too big changes which means too big regressions
for our released CUPS versions from my point of view.

3. What we could do for our released CUPS versions:

From my current point of view - the only possible way out
for our released CUPS versions is:

3a. No changes how CUPS behaves (i.e. keep cupsd.conf editing as is).

3b. Make sure that by default only root is allowed
    to do CUPS admin tasks:

Currently by default the user root and users in the groups
root and sys are allowed to do CUPS admin tasks.

By default only the user root belongs to the group root and
no user belongs to the group sys (according to /etc/passwd
and /etc/group on my SLED11-SP2 workstation).

But on our customers' systems there may be other users in the
groups root and sys and our customers may not know that this
means that those users are also allowed to do CUPS admin tasks.

Therefore I suggest to change the CUPS defaults so that the user root
and only users in the group root are allowed to do CUPS admin tasks
(via the configure option "--with-system-groups=root").

If a customer really wants that users in the group sys are allowed
to do CUPS admin tasks, he can (and now must) manually specify this
explicitly in /etc/cups/cupsd.conf via "SystemGroup root sys".

Of course I will document this change in the CUPS defaults
the RPM changelog.

3c. Make sure our customers know what it means to allow
    non-root users to do CUPS admin tasks.

Via this security update I will provide sufficient information
in the RPM changelog entry and furthermore the security team
can provide more explanatory information via the securtity
update notes.

4. Bottom line:

As far as I understand the issue from my current point of view
- we cannot really fix it (fix causes severe regressions)
- we are secure by default (but a possible group sys issue exists)
- we will be really secure by default (really only root is CUPS admin)
- we will inform our customers what "CUPS admin" actually means

I submitted my comment#18 regardless of a mid-air collision
with comment#17 that changed Deadline from 2012-11-28 to 2013-02-28
but my comment#18 re-set Deadline to 2012-11-28.
I re-re-set Deadline to 2013-02-28 via this comment.

Johannes, thank you for your summary. I will go through it as soon as possible,
but I think it won't be before next week.

Created attachment 542517 [details]
RHEL5 patch

I prefer solution #2, but I don't think anybody else likes it and therefore I
would suggest to agree on something everybody can accept. What about solution
#3 or #4?

Let's, however, also ask the other security guys, I don't want to overslaugh
them.

From my point of view, if there is a low-risk, effective programmatic fix that
addresses the currently known vulnerabilities, we should apply it.

In addition, the security advisory and the documentation should mention the
fact that adding users to the sys and root groups is a bad idea anyway
(this is what group wheel is for) - and that, in particular, membership in
these groups gives certain privileges to cups users. "As a matter of caution,
we advise our customers yadda yadda ..."

Let's finish discussing this bug and finally kill it :)

Update released for: cups, cups-client, cups-debuginfo, cups-debugsource, cups-devel, cups-libs, cups-libs-32bit
Products:
SLE-SERVER 11-SP1-TERADATA (x86_64)

Update released for: cups, cups-client, cups-debuginfo, cups-debugsource, cups-devel, cups-libs, cups-libs-32bit, cups-libs-x86
Products:
SLE-DEBUGINFO 11-SP2 (i386, ia64, ppc64, s390x, x86_64)
SLE-DESKTOP 11-SP2 (i386, x86_64)
SLE-SDK 11-SP2 (i386, ia64, ppc64, s390x, x86_64)
SLE-SERVER 11-SP2 (i386, ia64, ppc64, s390x, x86_64)
SLES4VMWARE 11-SP2 (i386, x86_64)

Update released for: cups, cups-client, cups-debuginfo, cups-debugsource, cups-devel, cups-libs, cups-libs-32bit, cups-libs-x86
Products:
SLE-DEBUGINFO 11-SP3 (i386, ia64, ppc64, s390x, x86_64)
SLE-DESKTOP 11-SP3 (i386, x86_64)
SLE-SDK 11-SP3 (i386, ia64, ppc64, s390x, x86_64)
SLE-SERVER 11-SP3 (i386, ia64, ppc64, s390x, x86_64)
SLES4VMWARE 11-SP3 (i386, x86_64)

fixed

This is an autogenerated message for OBS integration:
This bug (789566) was mentioned in
https://build.opensuse.org/request/show/222282 Factory / cups

An update workflow for this issue was started.
This issue was rated as moderate.
Please submit fixed packages until 2014-07-14.
When done, reassign the bug to security-team@suse.de.
https://swamp.suse.de/webswamp/wf/58116

SUSE-SU-2014:1023-1: An update that solves one vulnerability and has three fixes is now available.

Category: security (low)
Bug References: 789566,802408,827109,887240
CVE References: CVE-2014-3537
Sources used:
SUSE Linux Enterprise Server 11 SP1 LTSS (src):    cups-1.3.9-8.46.52.2