Bugzilla – Bug 923909
VUL-2: CVE-2014-8166: cups: code execution via unescape ANSI escape sequences
Last modified: 2020-04-01 22:13:29 UTC
Nothing specifically new Date: Mon, 23 Mar 2015 22:42:08 -0600 From: Kurt Seifried <kseifried@redhat.com> Subject: [oss-security] CVE-2014-8166 cups: code execution via unescape ANSI escape sequences So this one is pretty hard to cause exploitation without heavy social engineering/etc. https://bugzilla.redhat.com/show_bug.cgi?id=3D1084577 It was reported that ANSI escape sequences could be added to printer names in CUPS. Becaue CUPS has a browsing feature that, when enabled, allows remote hosts to announce shared printers, a malicious host or user could send a specially-crafted UDP packet to a CUPS server announcing an arbitrary printer name that includes ANSI escape sequences. Since the CUPS daemon does not remove these characters, a user on the targeted system could query the printer list (using 'lpstat -a', for example). If this were done in a terminal that supported the ANSI escape sequences (like a terminal with support for color), then code execution could be possible as the terminal would interpret the ANSI escape sequences contained in the printer name. A patch for this is available at https://bugzilla.redhat.com/attachment.cgi?id=3D916761 My apologies, this issue has been sitting way to long and is certainly not worth a long embargo. I can't wait till I'm done cleaning house of all these embargoed issues that shouldn't be embargoed. I strongly urge other vendors to do the same References: https://bugzilla.redhat.com/show_bug.cgi?id=1084577 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8166 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8166
bugbot adjusting priority
Typos in the mail from Kurt Seifried in comment#0: Red Hat bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1084577 Red Hat patch is: https://bugzilla.redhat.com/attachment.cgi?id=916761
I think the isssue does not need to be fixed because I think it is just one more possibility what a malicious user in a network could do when others blindly accept his bad stuff. See https://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings -------------------------------------------------------------------- First and foremost ... It is crucial to limit access to CUPS to trusted users. -------------------------------------------------------------------- In particular it is well known that CUPS Browsing must only happen in an internal trusted network. The basic description in comment#0 is: -------------------------------------------------------------------- a malicious host or user could send a specially-crafted UDP packet to a CUPS server announcing an arbitrary printer name that includes ANSI escape sequences. Since the CUPS daemon does not remove these characters, a user on the targeted system could query the printer list -------------------------------------------------------------------- I think accepting arbitrary remote information is the root cause here. One simply must never accept arbitrary remote information. A real CUPS print server machine will not be configured by the admin that it accepts arbitrary remote print queue information from any (remote) host. When the "CUPS server" is a cupsd on an end-user client system, see in particular what I wrote at https://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings -------------------------------------------------------------------- The crucial point regarding network security is that client hosts must not accept remote print queue information from untrusted (i.e. external) CUPS servers. ... See the "print job phishing" thread on the "cups" mailing list from August 2007 http://www.cups.org/pipermail/cups/2007-August/thread.html ... by default the firewall rejects or drops any remote print queue information from any host so that client hosts are protected against "print job phishing". --------------------------------------------------------------------
Software systems should attempt to protect users from unnecessarily grave consequences even in the case of otherwise insecure configurations. I do not know what kind of useful functionality could be drawn from not filtering ANSI characters, regardless of what the common/recommended configuration is. (But I agree on what it should be) There is certainly an upstream *intention* on what a valid printer name should be, compare scheduler/ipp.c validate_name(). The notion of a trusted network should be used with great care. No such thing really exists and many attacks originate from the inside of whatever perimeter is considered. Having said that... VUL-2/WONTFIX. No submission necessary at this time, but will be re-considered upon request. This hasn't really gone upstream either. The proposed patch does not apply to SLE 12.
An addendum FYI regarding "re-considered": I assume there are many other cases where whatever data that is currently presented in this or that way by the cupsd (e.g. via its web-interface or in any kind of IPP response) to end-users is not yet sufficiently sanitized. If the issue is re-considered, I would appreciate it when there is a more general security audit what the cupsd does with all its input data. Users who are allowed to submit print jobs are basically allowed to upload arbitrary data onto the CUPS server (the print job data plus print job control values) and then various programs run on the CUPS server (cupsd, various filters and backends, arbitrary printer drivers) that work with the data in various ways so that in the end all together lead to a zillion of ways how the data is processed depending on the particular environment. From my personal point of view it is currently hopeless to make a CUPS print server system really secure against malicious users who are allowed to submit print jobs. This is the basic reason behind why I wrote https://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings I think currently CUPS simply cannot be used in an environment where one does not know who the persons are that submit print jobs because there are too many possibilities for users who are allowed to submit print jobs to trigger "bad things" on the CUPS server.
I enhanced https://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings therein in the section "What is Specific Regarding Firewall Setup for Printing" I added what I wrote above in comment#5