[Pkg-cups-devel] Bug#692791: #692791 - CVE-2012-5519 - cups lpadmin-to-root privilege escalation - Proposed solutions

[Didier 'OdyX' Raboud]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-cups-devel/attachments/20121129/7f305709/attachment.pgp>