From the oss-security mailing list at $URL:
"a Debian user reported a bug in our BTS concerning cupsd. The bug is
available at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692791 and
upstream bug at http://www.cups.org/str.php?L4223 (restricted because
it's tagged security).
I'm unsure right now if it's an upstream issue or specific to Debian.
Basically, members of the lpadmin group (which is the group having admin
rights to cups, meaning they're supposed to be able to add/remove
printeers etc.) have admin access to the web interface, where they can
edit the config file and set some “dangerous” directives (like the log
filenames), which enable them to read or write files as the user running
the cupsd webserver.
In Debian case at least, it's run as root, meaning we have a privilege
escalation issue from lpadmin group to root."
The issue also affects Gentoo: users of the lpadmin group can use the script in the Debian bug report to read files.
Red Hat bug:
CUPS 1.4.4, when running in certain Linux distributions such as Debian
GNU/Linux, stores the web interface administrator key in
/var/run/cups/certs/0 using certain permissions, which allows local users in
the lpadmin group to read or write arbitrary files as root by leveraging the
Cups 1.4.4 is already long gone from portage.
(In reply to comment #2)
> Cups 1.4.4 is already long gone from portage.
This issue is fixed in 1.6.2 . May we proceed to stabilize =net-print/cups-1.6.2 ?
I already have a tracker for cups-1.6 stabilization. Soon, please wait for the blocker to resolve.
(It does not help that upstream cups bugtracker is still offline.)
(In reply to Sean Amoss from comment #3)
> (In reply to comment #2)
> > Cups 1.4.4 is already long gone from portage.
> This issue is fixed in 1.6.2 . May we proceed to stabilize
> =net-print/cups-1.6.2 ?
>  http://www.cups.org/articles.php?L689+TNews+Q
Please proceed with stabilization, using the following versions:
I'll leave it to you to add arches; it's better if this goes through sec team channels.
(In reply to Andreas K. Hüttel from comment #5)
> Please proceed with stabilization, using the following versions:
> I'll leave it to you to add arches; it's better if this goes through sec
> team channels.
Thanks, Andreas. Arches teams, please test and mark stable.
Stable for HPPA.
All keywords dropped in vulnerable versions, except slow arches m68k and s390
@m68k: when you wake up, please immediately go for
m68k can continue to work while we vote. GLSA vote: yes (potential priv escalation, even if it's a specific set of users).
GLSA vote: yes
New GLSA request filed
M68K is not anymore a stable arch, removing it from the cc list
Nothing to do for printing here anymore
This issue was resolved and addressed in
GLSA 201404-01 at http://security.gentoo.org/glsa/glsa-201404-01.xml
by GLSA coordinator Sergey Popov (pinkbyte).