Warning message

Log in to add comments.

Enterprise Linux 6.4 to 6.5 risk report

Mark J. Cox published on 2013-11-27T13:00:55+00:00, last updated 2013-11-27T13:00:55+00:00

Red Hat Enterprise Linux 6.5 was released last week (November 2013), nine months since the release of 6.4 in February 2013. In this report we take a look back over the vulnerabilities and security updates since that last update, specifically for Red Hat Enterprise Linux 6 Server.

Red Hat Enterprise Linux 6 is in its fourth year since release, and will receive security updates until November 30th 2020.

Errata count

The chart below illustrates the total number of security updates issued for Red Hat Enterprise Linux 6 Server if you had installed 6.4, up to and including the 6.5 release, broken down by severity. The chart is split into two columns, one for the packages you'd get if you did a default install, and the other if you installed every single package.

During installation, there actually isn't an option to install every package, you'd have to manually select them all, which is not a likely scenario. For a given installation, the number of package updates and vulnerabilities that affected you will depend on exactly what you selected during installation and which packages you have subsequently installed or removed.

 

20131121a

 

For a default install, from the release of 6.4 up to and including 6.5, we shipped 54 advisories to address 228 vulnerabilities. 3 advisories were rated critical, 18 were important, and the remaining 33 were moderate and low.

For all packages, from the release of 6.4 up to and including 6.5, we shipped 127 advisories to address 399 vulnerabilities. 17 advisories were rated critical, 40 were important, and the remaining 70 were moderate and low.

You can cut down the number of security issues you need to deal with by carefully choosing the right Red Hat Enterprise Linux variant and package set when deploying a new system, and ensuring you install the latest available Update release.

 

Critical vulnerabilities

Vulnerabilities rated with a critical severity are the ones that can pose the most risk to an organisation. By definition, a critical vulnerability is one that could be exploited remotely and automatically by a worm. However, we also stretch that definition to include those flaws that affect web browsers or plug-ins where a user only needs to visit a malicious (or compromised) website in order to be exploited. Most of the critical vulnerabilities we fix fall into that latter category.

The 19 critical advisories addressed 83 critical vulnerabilities across four different projects:

  1. An update to PHP: RHSA-2013:1049 (Jul 2013). If a PHP application used a particular function to parse untrusted XML content, a remote attacker able to supply specially crafted XML could use this flaw to crash the application or, possibly, execute arbitrary code.
  2. Updates to the OpenJDK 7 Java Runtime: RHSA-2013:1451 (Oct 2013), RHSA-2013:0957 (Jun 2013), RHSA-2013:0751 (Apr 2013), RHSA-2013:0602 (Mar 2013), and OpenJDK 6 Java Runtime: RHSA-2013:0605 (Mar 2013), RHSA-2013:0273 (Feb 2013), RHSA-2013:0245 (Feb 2013), where a malicious web site presenting a Java applet could potentially run arbitrary code as the user running the web browser.
  3. Updates to Firefox/XULRunner: RHSA-2013:1476 (Oct 2013), RHSA-2013:1268 (Sep 2013), RHSA-2013:1140 (Aug 2013), RHSA-2013:0981 (Jun 2013), RHSA-2013:0820 (May 2013), RHSA-2013:0696 (Apr 2013), RHSA-2013:0614 (Mar 2013), RHSA-2013:0271 (Feb 2013), where a malicious web site could potentially run arbitrary code as the user running Firefox.
  4. An update to Thunderbird: RHSA-2013:0272 (Feb 2013), where a malicious email message could potentially run arbitrary code as the user running Thunderbird.

Updates to correct 60 of the 83 critical vulnerabilities (72%) were available via Red Hat Network either the same day or the next calendar day after the issues were public.

Not counting updates to OpenJDK, this number would have been 100%. Two OpenJDK updates both took 7 days due to a number of problems with the packages, including requiring respins after failing QA, and broken fixes and regressions from upstream.

Overall, for Red Hat Enterprise Linux 6, from the release of 6.0 up to and including 6.5, 90% of the critical vulnerabilities have had an update that addressed these issues available from the Red Hat Network either the same day or the next calendar day after the issue was public.

Other significant vulnerabilities

Although not in the definition of critical severity, also of interest are remote denial of service flaws and local privilege escalation flaws:

  • A flaw in dbus-glibc: CVE-2013-0292 fixed by RHSA-2013:0568 (Feb 2013). A local attacker could use this flaw to escalate their privileges to root. A public exploit exists for this issue.
  • A flaw in the Tomcat init scripts: CVE-2013-1976 fixed by RHSA-2013:0869, where a local user who could deploy a Tomcat application could gain root privileges. This issue is considered to be easily exploitable.
  • A race condition was found in PolicyKit. Packages that used PolicyKit authorization could have intended authorizations bypassed, or in certain conditions users could escalate their privileges: CVE-2013-4288 fixed by RHSA-2013:1270 in polkit, CVE-2013-4311 fixed by RHSA-2013:1272 in libvirt, CVE-2013-4324 fixed by RHSA-2013:1273 in spice-gtk, CVE-2013-4325 fixed by RHSA-2013:1274 in hplip, CVE-2013-4326 fixed by RHSA-2013:1282 in rtkit. A proof of concept for this flaw is available.
  • Various flaws in the kernel:
    • CVE-2013-2094, fixed by RHSA-2013:0830, (May 2013) could allow a local unprivileged user to gain root privileges; a public exploit exists for this issue.
    • CVE-2013-0268, fixed by RHSA-2013:0630, (Mar 2013) could allow a local root user who has limited capabilities the ability to further escalate their privileges; a public exploit exists for this issue.
    • CVE-2013-0871, fixed by RHSA-2013:0567, (Feb 2013) could allow a local unprivileged user to gain root privileges. In practice, our testing showed the involved race condition is hard to win, even with the publicly available exploit.
    • CVE-2013-0913, fixed by RHSA-2013:0744, (Apr 2013) could allow a local unprivileged user to gain root privileges. We have not seen a public exploit for this issue, but it was supposedly used in a competition as part of an exploit against Google Chrome OS.
    • CVE-2013-1935, fixed by RHSA-2013:0911, where an unprivileged KVM guest user could potentially crash the host.
    • Other kernel flaws were fixed that could potentially allow escalation of privileges, but either were hard to exploit, or currently have no public exploits available, such as CVE-2013-0228, CVE-2013-1773, CVE-2013-1796, CVE-2013-1797, CVE-2013-1943, and CVE-2013-2224.
  • Two flaws in BIND: CVE-2013-2266 fixed by RHSA-2013:0689 (Mar 2013), and CVE-2013-4854 fixed by RHSA-2013:1114 (Jul 2013). A remote attacker could use either of these flaws to cause BIND to crash. We are not aware of a specific exploits for these issues, but they could be easily created.
  • A flaw in the 389 Directory Server: CVE-2013-4283 fixed by RHSA-2013:1182, which could cause the Directory Server to crash. We are not aware of a public exploit for this issue.
  • A flaw in the GnuTLS library: CVE-2013-2116 fixed by RHSA-2013:0883. A remote attacker could use this flaw to crash a server application that uses GnuTLS. We are not aware of a public exploit for this issue.

Previous update releases

We generally measure risk in terms of the number of vulnerabilities, but the actual effort in maintaining a Red Hat Enterprise Linux system is more related to the number of advisories we released: a single Firefox advisory may fix ten different issues of critical severity, but takes far less total effort to manage than ten separate advisories each fixing one critical PHP vulnerability.

To compare these statistics with previous update releases, we need to take into account that the time between each update release is different. So looking at a default installation and calculating the number of advisories per month gives the following chart:20131121b

This data is interesting to get a feel for the risk of running Enterprise Linux 6 Server, but is not really useful for comparisons with other major versions, distributions, or operating systems — for example, a default install of Red Hat Enterprise Linux 6 Server does not include Firefox, but 5 Server does. You can use our public security measurement data and tools to run your own custom metrics for any given Red Hat product, package set, timescales, and severity range of interest.

See also: 6.4, 6.3, 6.2, and 6.1 risk reports.

English

About The Author

Mark J. Cox's picture Red Hat Community Member 25 points

Mark J. Cox

Mark J Cox lives in Scotland and for 2000 to 2018 was the Senior Director of Product Security at Red Hat. Mark has developed software and worked on the security teams of popular open source projects including Apache and OpenSSL. Mark is a founding member of the Apache Software Foundation and the Ope...