[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 11 Nov 2012 00:18:13 -0700
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: Yves-Alexis Perez <corsac@...ian.org>, 692791@...s.debian.org,
team@...urity.debian.org, cups-security@...le.com
Subject: Re: Privilege escalation (lpadmin -> root) in cups
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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>
so that should be like "root", "bin" and "adm" so yeah it would appear
to be vendor specific.
> 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.
> Regards,
>
- --
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJQn1E1AAoJEBYNRVNeJnmTAk0QAJzI9+STxsFAL7YJm4obCLAY
PhVVZYau19qUxMlMEIahfvcV46/36zYZPKYtNJCNtH7G30lPqC2gfZ3upNbri8+u
71tZw15UMU6qAt/WNpfe9URjSNHRcO8tJ6OqN6u6er13YhdVkls6/Yudty1hAZoU
wqd1xcBDv2uhaOsI5SswfSHC61JkBLRD7f13T6eWfSz5VT1TBwzJyP5yLTygx4jt
wRnF/dBUSToSSqlLyP1gdSJWs6ksTtaVc7vHkCD2NVCZMPOn9lm9RiVj52Q1e/eR
osbqbCwx8P3FC4w+MvN29+GbfRxdFA6ik4IHrpzR3Q+j105aQwIm0pubsENA2Lr3
YHnvoD4oysfr3zUGYs5dbH1qITTw2t5c2oAP1wfG7C52jjblg3AaDDSgACyJFciQ
kqcmSnDdBdcpc9dpGFo02LSOkh1jyVmBUCjTfXiNkpTtMv++CtgGdQM6j/UgAh1Q
28yf5WhxuhdGPo28XNWbYj9ELAe4aDAssggTL+ysM8Xjc23hfBXowCNbkO4LqrlQ
S14M04wi4eHrd8sj+DpzODm9ttOrnCCmzuNc5UBlxH2Mxk6LUVczU5RwDJ/wFPKA
DoHFiCldax69zjRsLv/wgu3oNfn8Hi3Piyn/TfGmFEnnnejCUe5lDUIRzZgj+LoB
62nQOCDF/bsxQWwJdDPl
=zMgY
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
