Re: Privilege escalation (lpadmin -> root) in cups

[Yves-Alexis Perez <corsac () debian org>]

On dim., 2012-11-11 at 00:18 -0700, Kurt Seifried wrote:
> On 11/10/2012 05:49 AM, Yves-Alexis Perez wrote:
> > Hi,
> >
> > 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.
>
> On Red Hat Enterprise 6 and Fedora 16 the file is owned by root:sys,
> and the cupsd.conf defaults to:
>
> <Location /admin/conf>
>   AuthType Default
>   Require user @SYSTEM
>   Order allow,deny
> </Location>

As far as I can tell, @SYSTEM is defined using SystemGroup and defaults
to lpadmin.
> so that should be like "root", "bin" and "adm" so yeah it would appear
> to be vendor specific.

Well, in Debian (and upstream) case it's lpadmin -> root but in your
case it'd be bin -> root and adm -> root. Maybe adm is intended to be
root anyway but I guess that's not the case for bin?

The whole point is that people with access to the admin web interface
can force cupsd to read or write files with the user running cupsd
(root).
> > 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.
>
> I think as a rule cupsd runs as root, to touch the various files/dirs/etc.
>
> > A fix would be to not run cupsd web server as root, and maybe to 
> > restrict it to some kind of chroot so it doesn't have access to 
> > sensitive files
>
> Tricky, /dev/*, log dirs, etc. Probably better to just use a print
> specific user/group and make all the standard locations owned by it,
> and require the admin to setup anything like say
> /non-standard/log/printers/ and so on.
>
> > Can a CVE be allocated for this?
>
> Please use CVE-2012-5519 for this issue. Also if other vendors could
> check the permissions/configs/etc. and reply if they are vulnerable
> that would be good.

Thanks.

Regards,
-- 
Yves-Alexis

Attachment: signature.asc
Description: This is a digitally signed message part