Security
OpenSSL's new security policy
The OpenSSL project is widely known due to its broad adoption as the SSL/TLS library of choice for open-source software—though, in April, it also became widely known because of a particularly vicious security vulnerability. To a large degree, the project weathered the storm, but the project has also undertaken some changes in the wake of the incident. The most recent is the adoption of a public security policy describing how issues of various kinds will be dealt with.
The "Heartbleed" vulnerability disclosed in April was, as has been discussed ad nauseam, a black eye for OpenSSL, but it also served as a wake-up call to the tech industry in general, especially to the large corporations that depend on OpenSSL's security for their own product lines. In May, the Linux Foundation (LF) announced a new program called the Core Infrastructure Initiative (CII) that was designed to financially support critical software projects like OpenSSL that have had a difficult time raising support for developers on their own. A number of major technology-industry players announced pledges of money to the CII cause and in May the LF announced that OpenSSL, OpenSSH, and Network Time Protocol (NTP) would be the first projects to receive funding.
OpenSSL, specifically, would be hiring two developers to work on the project full time, and Matt Green of the Open Crypto Audit Project would be paid to conduct a security audit of the codebase. The Economist's Schumpeter blog reported that the two CII-funded developers would be longtime contributors Stephen Henson and Andy Polyakov.
But putting paid developers to work is only one part of getting OpenSSL's house in order. In recent months, the project has taken a number of smaller steps to formalize—at least, publicly—its processes and procedures. On June 30, a roadmap was published, outlining several objectives the project intends to target in the coming weeks and months. Few of the entries would surprise free-software developers, as they enumerate common challenges: improving coding style, reducing the issue backlog, improving documentation, etc. Others include making some project-wide decisions, such as establishing a code-review policy and a platform strategy; processes that are underway.
Defining and publishing a security strategy was one of these roadmap items, and when the policy was announced on September 7, it was duly marked off of the list.
Policy
The security policy outlines OpenSSL's preferred procedure for outsiders to report possible vulnerabilities, how the project classifies vulnerabilities, and what the project's procedures are for publishing fixes and for notifying downstream projects and other organizations.
The procedure for reporting vulnerabilities, unsurprisingly, is to contact the project via email (optionally using PGP encryption). From there, if the OpenSSL team determines that there is a real vulnerability, it will (in private) classify the vulnerability as a low-, medium-, or high-severity issue. Low severity, the policy explains, applies to command-line utilities, unlikely configurations, and difficult-to-exploit issues like side-channel attacks. Medium severity encompasses client-side crashes, local flaws, and uncommon protocols. High severity is reserved for issues with common configurations that are likely to be exploitable.
These three classifications have ramifications for how OpenSSL will
respond with its security fixes. A low-severity issue, according to
the policy, will be fixed as soon as possible in the development
branch, and "may be backported to older versions that are still
getting updates
". In either case, the project's
vulnerabilities page and changelog will be updated
when the fix is committed, but the fix
will not necessarily trigger a new OpenSSL release.
Medium-severity issues, in contrast, will be kept private up until a new release is ready to be made. Nevertheless, new releases are expected to push out several such fixes at a time, rather than a new release being rolled out for any one such issue. The policy does not explicitly mention the backporting of medium-severity fixes, although since backports may be for low-severity fixes, it stands to reason that they would be more likely for more serious vulnerabilities.
High-severity issues, however, will prompt a new release
of OpenSSL for all supported versions. As with medium-security
issues, the existence of the vulnerability will be kept private until
the release is ready for rollout. But the project vows that it will
"attempt to keep the time these issues are private to a minimum;
our aim would be no longer than a month where this is something under
our control, and significantly quicker if there is a significant risk
or we are aware the issue is being exploited.
"
Private practices
Naturally, the notion of keeping OpenSSL vulnerabilities private is one that may irk some software vendors and downstream projects. The "Background" section of the security policy makes the argument that disclosing vulnerabilities prior to the availability of a solution increases the likelihood of an exploit, but it also touts the benefits of peer review for patches. Finding the right balance, of course, is the tricky part.
In practice, the policy explains, OpenSSL's definition of "private" is quite specific. The project will announce upcoming releases on its openssl-announce mailing list, noting the approximate release date but not disclosing or describing the affected vulnerabilities in detail. The goal is to allow downstream users to put staff in place ready to deal with the new release once it is made, at which time the vulnerability will be disclosed.
Operating system vendors will receive somewhat more preferential treatment when the new release fixes a high-severity issue. To that end, the project uses the invitation-only distros mailing list hosted by Openwall, plus additional organizations selected by the OpenSSL project. The participating organizations receive prenotification of severe vulnerabilities and can provide testing and feedback with regard to patches.
Membership on this mailing list is a tightly managed affair, which has been the source of disagreements in the past, since inclusion gives a vendor advance warning of potentially useful vulnerability information. But the purpose of that prenotification is to improve the fixes so that vendors can release package updates ready when the vulnerability is disclosed, because so many OpenSSL users rely on their operating system's packages. It is not simply a "preferred client" program.
Such a distinction is not always clear, at least if history is any guide. In June, for example, VMware requested to be added to the Openwall linux-distros list (linux-distros is a subset of the distros list, which also includes FreeBSD and NetBSD). The company's request was denied when (among others) Greg Kroah-Hartman argued that although VMware uses many open-source software components—including the Linux kernel—it does not contribute back to the community. Being a participating, contributing member of the open-source community is a prerequisite for being eligible to receive prenotifications.
The OpenSSL policy incorporates wording in several places to distinguish between the feedback aspect of vulnerability prenotification and its potential for commercial exploitation. The Background section notes:
and, later:
In addition, the section of the policy describing the prenotification process reiterates that the intent is to improve the resulting fixes. As such, OpenSSL may decide that any particular organization (among those OpenSSL has selected in addition to the distros list) is not advancing this goal, and thus remove it unilaterally:
On the openssl-dev list, it was this clause that prompted the only question to be asked about the new policy so far. Loganaden Velvindron requested additional clarification of the language describing how the project decides if a vendor is providing value, and asked if there was a rating system that the vendors themselves could refer to.
So far, Velvindron's question has received no response, which may suggest that the project and the members of the OpenSSL community, in general, just "know" the difference between a vendor that is providing value to the security handling process and one that is not. Certainly there are many portions of the newly published policy that draw on OpenSSL's long experience with handling vulnerabilities and releasing security updates. An increasing in funding may provide more developer attention, and it may result in more formal processes—but, for the most part, these changes are just further refinements of the work that OpenSSL has learned to do over many years of development.
Brief items
Security quotes of the week
Freenode server compromised
The freenode infrastructure team found a server issue that indicated that an IRC server may have been compromised. "We immediately started an investigation to map the extent of the problem and located similar issues with several other machines and have taken those offline. For now, since network traffic may have been sniffed, we recommend that everyone change their NickServ password as a precaution." (Thanks to Paul Wise)
New vulnerabilities
apt: multiple vulnerabilities
| Package(s): | apt | CVE #(s): | CVE-2014-0487 CVE-2014-0488 CVE-2014-0489 CVE-2014-0490 | ||||||||||||
| Created: | September 17, 2014 | Updated: | September 19, 2014 | ||||||||||||
| Description: | From the Debian advisory:
It was discovered that APT, the high level package manager, does not properly invalidate unauthenticated data (CVE-2014-0488), performs incorrect verification of 304 replies (CVE-2014-0487), does not perform the checksum check when the Acquire::GzipIndexes option is used (CVE-2014-0489) and does not properly perform validation for binary packages downloaded by the apt-get download command (CVE-2014-0490). | ||||||||||||||
| Alerts: |
| ||||||||||||||
axis: SSL hostname verification bypass
| Package(s): | axis | CVE #(s): | CVE-2014-3596 | ||||||||||||||||||||||||||||||||
| Created: | September 15, 2014 | Updated: | December 29, 2014 | ||||||||||||||||||||||||||||||||
| Description: | From the CVE entry:
The getCN function in Apache Axis 1.4 and earlier does not properly verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via a certificate with a subject that specifies a common name in a field that is not the CN field. NOTE: this issue exists because of an incomplete fix for CVE-2012-5784. | ||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||
conga: multiple vulnerabilities
| Package(s): | conga | CVE #(s): | CVE-2012-5485 CVE-2012-5486 CVE-2012-5488 CVE-2012-5497 CVE-2012-5498 CVE-2012-5499 CVE-2012-5500 CVE-2013-6496 CVE-2014-3521 | ||||||||||||||||
| Created: | September 16, 2014 | Updated: | October 14, 2014 | ||||||||||||||||
| Description: | From the Red Hat advisory:
It was discovered that Plone, included as a part of luci, did not properly protect the administrator interface (control panel). A remote attacker could use this flaw to inject a specially crafted Python statement or script into Plone's restricted Python sandbox that, when the administrator interface was accessed, would be executed with the privileges of that administrator user. (CVE-2012-5485) It was discovered that Plone, included as a part of luci, did not properly sanitize HTTP headers provided within certain URL requests. A remote attacker could use a specially crafted URL that, when processed, would cause the injected HTTP headers to be returned as a part of the Plone HTTP response, potentially allowing the attacker to perform other more advanced attacks. (CVE-2012-5486) Multiple information leak flaws were found in the way conga processed luci site extension-related URL requests. A remote, unauthenticated attacker could issue a specially crafted HTTP request that, when processed, would result in unauthorized information disclosure. (CVE-2013-6496) It was discovered that various components in the luci site extension-related URLs were not properly restricted to administrative users. A remote, authenticated attacker could escalate their privileges to perform certain actions that should be restricted to administrative users, such as adding users and systems, and viewing log data. (CVE-2014-3521) It was discovered that Plone, included as a part of luci, did not properly protect the privilege of running RestrictedPython scripts. A remote attacker could use a specially crafted URL that, when processed, would allow the attacker to submit and perform expensive computations or, in conjunction with other attacks, be able to access or alter privileged information. (CVE-2012-5488) It was discovered that Plone, included as a part of luci, did not properly enforce permissions checks on the membership database. A remote attacker could use a specially crafted URL that, when processed, could allow the attacker to enumerate user account names. (CVE-2012-5497) It was discovered that Plone, included as a part of luci, did not properly handle the processing of requests for certain collections. A remote attacker could use a specially crafted URL that, when processed, would lead to excessive I/O and/or cache resource consumption. (CVE-2012-5498) It was discovered that Plone, included as a part of luci, did not properly handle the processing of very large values passed to an internal utility function. A remote attacker could use a specially crafted URL that, when processed, would lead to excessive memory consumption. (CVE-2012-5499) It was discovered that Plone, included as a part of luci, allowed a remote anonymous user to change titles of content items due to improper permissions checks. (CVE-2012-5500) | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
curl: two cookie-handling vulnerabilities
| Package(s): | curl | CVE #(s): | CVE-2014-3613 CVE-2014-3620 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | September 11, 2014 | Updated: | October 9, 2014 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Debian advisory:
CVE-2014-3613: By not detecting and rejecting domain names for partial literal IP addresses properly when parsing received HTTP cookies, libcurl can be fooled to both sending cookies to wrong sites and into allowing arbitrary sites to set cookies for others. CVE-2014-3620: libcurl wrongly allows cookies to be set for Top Level Domains (TLDs), thus making them apply broader than cookies are allowed. This can allow arbitrary sites to set cookies that then would get sent to a different and unrelated site or domain. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
dbus: multiple vulnerabilities
| Package(s): | dbus | CVE #(s): | CVE-2014-3635 CVE-2014-3636 CVE-2014-3637 CVE-2014-3638 CVE-2014-3639 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | September 17, 2014 | Updated: | December 22, 2014 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Debian advisory:
Alban Crequy and Simon McVittie discovered several vulnerabilities in the D-Bus message daemon. CVE-2014-3635: On 64-bit platforms, file descriptor passing could be abused by local users to cause heap corruption in the dbus-daemon crash, leading to a crash, or potentially to arbitrary code execution. CVE-2014-3636: A denial-of-service vulnerability in dbus-daemon allowed local attackers to prevent new connections to dbus-daemon, or disconnect existing clients, by exhausting descriptor limits. CVE-2014-3637: Malicious local users could create D-Bus connections to dbus-daemon which could not be terminated by killing the participating processes, resulting in a denial-of-service vulnerability. CVE-2014-3638: dbus-daemon suffered from a denial-of-service vulnerability in the code which tracks which messages expect a reply, allowing local attackers to reduce the performance of dbus-daemon. CVE-2014-3639: dbus-daemon did not properly reject malicious connections from local users, resulting in a denial-of-service vulnerability. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
libreoffice: two vulnerabilities
| Package(s): | LibreOffice | CVE #(s): | CVE-2013-4156 CVE-2014-3575 | ||||||||||||||||||||||||||||||||||||||||
| Created: | September 11, 2014 | Updated: | November 14, 2014 | ||||||||||||||||||||||||||||||||||||||||
| Description: | From the CVE entries:
CVE-2014-3575: The OLE preview generation in Apache OpenOffice before 4.1.1 and OpenOffice.org (OOo) might allow remote attackers to embed arbitrary data into documents via crafted OLE objects. CVE-2013-4156: Apache OpenOffice.org (OOo) before 4.0 allows remote attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact via a crafted element in an OOXML document file. | ||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||
moodle: two vulnerabilities
| Package(s): | moodle | CVE #(s): | |||||
| Created: | September 15, 2014 | Updated: | September 17, 2014 | ||||
| Description: | From the Moodle 2.6.5 release notes:
MSA-14-0033 URL parameter injection in CAS authentication MSA-14-0034 Identity information revealed early in Q&A forum | ||||||
| Alerts: |
| ||||||
php5: insecure temporary files
| Package(s): | php5 | CVE #(s): | CVE-2014-5459 | ||||||||||||
| Created: | September 16, 2014 | Updated: | September 17, 2014 | ||||||||||||
| Description: | From the openSUSE advisory:
Insecure temporary file use for cache data was fixed by switching to a different root only directory /var/cache/php-pear | ||||||||||||||
| Alerts: |
| ||||||||||||||
qemu: information leak
| Package(s): | qemu | CVE #(s): | CVE-2014-3615 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | September 11, 2014 | Updated: | December 3, 2014 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla entry:
An information leakage flaw was found in Qemu's VGA emulator. It could lead to leaking host memory bytes to a VNC client. It could occur when a guest GOP driver attempts to set a high display resolution. A privileged user/program able to set such high resolution could use this flaw to leak host memory bytes. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Page editor: Jake Edge
Next page:
Kernel development>>