Hi all, (Security and Release Teams CC'ed to get their advice) As this is now going in several directions, let's try to summarize the proposed solutions to get this privilege escalation fixed.
A) Move configuration stanzas from cupsd.conf to cups-files.conf
This is the patch at [0], from upstream revisions 10710 and 10713 and Marc's
small-fixes patch on STR-4223.
This patch moves the following configuration settings from cupsd.conf to
cups-files.conf:
AccessLog CacheDir ConfigFilePerm DataDir
DocumentRoot
ErrorLog FileDevice FontPath
LogFilePerm LPDConfigFile
PageLog PrintCap RemoteRoot
RequestRoot ServerBin
ServerCertificate ServerKey
ServerRoot SMBConfigFile
StateDir SystemGroupAuthKey TempDir
Pidfile
Amongst thoses, only SystemGroup was defined in the default cupsd.conf (and
Pidfile is Debian-specific). cups-files.conf is not editable by lpadmin users,
and not from the webinterface. As far as I read and understand the patch, the
above list of configuration stanzas "just" generate warnings if they are found
in cupsd.conf.
Pros: + That's the correct long-term solution.
Cons: - Far from easy to migrate automatically, especially when cupsd.conf was
edited through the webinterface automagically.
- If putting these configuration stanzas in cupsd.conf just generates
warnings, what's the point of the exercise?
B) Disable any remote configuration by lpadmin users
This has been attempted by Marc on [1]. For now, it is incomplete as it still
allows lpadmin users to HTTP PUT updates to the configuration files.
Pros: + Addresses the problem in a way less intrusive way (smaller patch)
Cons: - Big loss of functionality through forbidding any lpadmin cups server
configuration
C) Ensure that logfiles paths are under CUPSD_LOGDIR /var/log/cups
This has been attempted by Michael on [2]. For now, it is proven to be too
weak as it lets attackers use /var/log/cups/../../../etc/shadow e.g. Also it
only checks the logfiles paths (and not DocumentRoot e.g.).
Pros: + Avoids the simple attack
Cons: - Doesn't really solve anything
D) Enforce default paths, override configuration settings
This has been presented as a possible solution: override the user configuration
settings with sane defaults.
Pros: + Avoids all possible attacks given sane defaults
Cons: - Breaks the test-suite that needs to redirect logfiles, DocumentRoot,
etc.
- Takes configuration freedom away from administrators;
- On upgrade, doesn't respect past configurations by administrators;
== Conclusion
In my opinion, A) is the correct long-term solution. It still needs some
additional scripting (move to ucf for cupsd.conf, preinst to move away what's
easily moved away, postinst to edit the new cups-files.conf with old values
from cupsd.conf. But this is probably way too intrusive for a stable upgrade.
Even for a fix targetted at testing, I suspect that this might be too
intrusive (+ the configuration file edit dance isn't written yet).
So, for squeeze/stable and wheezy/next-stable, I'd be tempted to go the B)
(to be fixed) way. Granted, we'll loose functionality, but it will put us on
the safe-side, with updates that drop functionality without needing a painful
configuration-files-edit upgrading path.
Opinions?
Cheers,
OdyX
[0]
http://anonscm.debian.org/gitweb/?p=pkg-cups/cups.git;a=blob;f=debian/patches/Split-configuration-files-STR-4223.patch
[1]
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=116;filename=CVE-2012-5519.patch;att=1;bug=692791
[2]
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=131;filename=alt-CVE-2012-5519.patch;att=1;bug=692791
signature.asc
Description: This is a digitally signed message part.
