The following flaw was found in CUPS:
Cupsd uses reference-counted strings with global scope. When parsing a print job request, cupsd over-decrements the reference count for a string from the request. As a result, an attacker can prematurely free an arbitrary string of global scope. They can use this to dismantle ACLs protecting privileged operations, and upload a replacement configuration file, and subsequently run arbitrary code on a target machine.
This bug is exploitable in default configurations, and does not require any special permissions other than the basic ability to print.
Red Hat would like to thank the CERT/CC for reporting this issue.
Created cups tracking bugs for this issue:
Affects: fedora-all [bug 1229979]
This issue has been addressed in the following products:
Red Hat Enterprise Linux 6
Red Hat Enterprise Linux 7
Via RHSA-2015:1123 https://rhn.redhat.com/errata/RHSA-2015-1123.html
cups-2.0.3-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
cups-1.7.5-17.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Disabling the cups web interface significantly reduces the impact of this security flaw.
With your update (thank you), we have a new score of 7.6:
Base Score: 7.6
Base Metrics: AV:N/AC:H/Au:N/C:C/I:C/A:C
Elsewhere, I see this noted as 9.3 as they're assessing the complexity of the exploit as being somewhat lower than we do:
https://www.kb.cert.org/vuls/id/810572 (CVE-2015-1158 && CVE-2015-1159):
The CVSS score below is based on CVE-2015-1158.
CVSS Metrics (Learn More)
Group Score Vector
Base 9.3 AV:N/AC:M/Au:N/C:C/I:C/A:C
The difference is that we have this classed as "High" complexity, and (at least some) others have this listed as "Medium" complexity, which would account for the scoring difference. Is there something specific to our setup which makes exploiting this more difficult/complex?
I can't seem to get NVD to actually load for the CVE, so I can't say what's there.
This issue affects the version of cups package as shipped with Red Hat Enterprise Linux 5. Red Hat Enterprise Linux 5 is now in Production 3 Phase of the support and maintenance life cycle. This has been rated as having Important security impact and is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata/.
(In reply to Frank Hirtz from comment #12)
> Hi Huzaifa,
> With your update (thank you), we have a new score of 7.6:
> Base Score: 7.6
> Base Metrics: AV:N/AC:H/Au:N/C:C/I:C/A:C
> Elsewhere, I see this noted as 9.3 as they're assessing the complexity of
> the exploit as being somewhat lower than we do:
> https://www.kb.cert.org/vuls/id/810572 (CVE-2015-1158 && CVE-2015-1159):
> The CVSS score below is based on CVE-2015-1158.
> CVSS Metrics (Learn More)
> Group Score Vector
> Base 9.3 AV:N/AC:M/Au:N/C:C/I:C/A:C
> The difference is that we have this classed as "High" complexity, and (at
> least some) others have this listed as "Medium" complexity, which would
> account for the scoring difference. Is there something specific to our setup
> which makes exploiting this more difficult/complex?
> I can't seem to get NVD to actually load for the CVE, so I can't say what's
Hi, Frank. There is indeed a difference between how NVD rates things and how we rate things. This is described on the Security Blog here:
That should clarify things for you.
Change of CVSV2 scores again:
Note: After more evaluation of the issues, it seemed like 6.8/AV:A/AC:H/Au:N/C:C/I:C/A:C was a better scoring, the only change is AV:A. This is because cups servers are not commonly configured/available on the internet, therefore Availability = Adjacent Network (Intranet) seems to be more suitable in this case. Everything else remains the same.
In order to exploit this flaw you need:
1. Permissions to print on the cups-server. Cups server are usually internal to a network, so this is not something which is exploitable on the internet.
2. This flaw has to be combined with other flaw, CVE-2015-1159 in this case. We do not rate security flaws in combination of what damage can be done with other issues.
3. Lastly exploitation is difficult and it needs exact conditions to be matches several of them are detailed on the external reference linked on the bug, there are others as well.
In addition to what Huzaifa noted above, this flaw requires that CUPS be listening to a network interface connected to the internet for it to be exploited by the general public. Typically, most CUPS installs listen to the localhost only (so the machine CUPS is running on) which is the shipped default. In cases of running a print server, this would listen on an ethernet interface but even then, unless there is a reason for having someone on the other side of the world print to your printer, there are firewalls in place to prevent unknown entities from performing an attack, which leaves only attackers on your local network.
In addition, this flaw requires that the CUPS web interface is also listening on a network-reachable port (again, by default, only the localhost). Note that just because you have CUPS listening for print requests on the local network it does not automatically mean that the web UI is available (this can be locked down to the localhost while still allowing for network printing).
As a result, this can be very easily mitigated even if you are using non-default configuration changes (which can only be made by a user with root privileges). If you need to permit web-based configuration via the UI, you can easily lock it down to a particular administrator IP (using either CUPS itself or iptables). See http://cups.org/documentation.php/doc-1.3/policies.html for more details.