CentOS is forever in catch-up mode. That's because it repackages Red Hat's Enterprise Linux (RHEL) for those who would prefer an enterprise distribution without the costs associated with RHEL. That regularly puts the distribution in something of a pinch, because Red Hat, quite reasonably, follows its own schedule for updates. That pinch is being felt strongly right now with two RHEL releases in quick succession (6.0 followed by 5.6). But it isn't just the distribution developers who are being pinched, as the security updates for CentOS 5 have also been held up by the ongoing work to release CentOS 5.6 and 6.0.
CentOS had already been struggling for a bit in its efforts to put out CentOS 6 after the release of RHEL 6 in November. Then, on January 13, Red Hat released its latest update for RHEL 5, 5.6. At that point, CentOS was faced with a bit of a dilemma: should it focus on 6.0 or work on 5.6 first? The decision was made to work on 5.6 and 6.0 in parallel more or less. That meant that CentOS had two fairly large jobs at hand.
With each Red Hat release, the CentOS developers need to go through the packages and remove any Red Hat-specific elements: artwork, trademarks, %description lines in RPM spec files, and so on. Once that's done, there is a QA process that the packages go through before a final release can be done. Turning RHEL 6 into CentOS 6 is a time-consuming process, but that's also true with 5.6. But there is an additional problem with 5.6: security updates.
Normally, CentOS follows along with Red Hat security updates, releasing its versions as quickly as it can after the RHEL update is released. But 5.6 (or any "point" release of RHEL) comes with a whole slew of updated packages, any of which might have a security update—or be a dependency of a package updated for security reasons. Since there are no CentOS 5.6 packages (yet), these security updates fall into a crack in the CentOS development process. CentOS can either backport the fixes into the 5.5 package, or release an updated 5.6 package along with all of its dependencies, some of which may not have passed the QA process yet.
Except for those updates that Red Hat has marked as "critical", CentOS has chosen to do neither of the above, according to lead developer Karanbir Singh. That may leave its users vulnerable to a number of potentially exploitable security holes. In email, Singh said that the CentOS team is looking at Red Hat's security updates to fix those that are deemed "remotely-exploitable", but that doesn't seem to jibe with what is getting released for CentOS 5. Since the release of RHEL 5.6, there have been no CentOS 5 security updates.
In fact, the last CentOS 5 security update was for the kernel on January 6, a week before RHEL 5.6 dropped. In the interim, Red Hat has released 22 updates, most with "low" or "moderate" impact, but a few that are "important" (two for the kernel, and one each for openoffice.org, krb5, and java-1.6.0-openjdk), and three "critical" bugs (java-1.5.0-ibm, flash-plugin, and java-1.6.0-sun). [Update: As pointed out in the comments (and by Singh), those last three packages are closed source and thus not distributed by CentOS.] There is also a pre-5.6 wireshark vulnerability that has yet to be patched. The full list can be seen here.
It may well be that some of those vulnerabilities only apply to the updated packages that came with RHEL 5.6, but it is extremely unlikely that's true of all of them. The critical Java updates are perhaps the most worrisome, since they come with vague vulnerability descriptions (e.g. "Unspecified vulnerability in the Swing component in Oracle Java SE and Java for Business 6 Update 21, 5.0 Update 25, 1.4.2_27, and 1.3.1_28 allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors."). The critical flash-plugin update is also of concern, but one would guess that there aren't all that many CentOS users running browsers with Flash on a server-oriented distribution.
It's also not at all clear that none of these vulnerabilities are remotely exploitable, as there are, at least, some remote denial of service flaws (which can sometimes be turned into remote exploits). For CentOS installations with untrusted users, there are plenty of locally exploitable flaws in the list. Even without untrusted users, a flaw in a content management system or other web application, for example, may provide an attacker the local access they need to use a local exploit to potentially compromise the entire system.
CentOS is pretty clearly dropping the ball on security updates here, which is probably not what its users expect. While the project is understaffed and is always looking for additional contributors, CentOS 5 users may not be aware that nearly two-dozen security updates (so far) have gone by the wayside while the QA process for 5.6 is ongoing. The CentOS FAQ clearly states that the goal is to have updates available in 72 hours after Red Hat puts them out and, by and large, the project meets that goal—except during the point-release gap.
That gap has stretched longer than the project would like, as Singh notes:
According to Singh, the 5.6 release is imminent ("within the next few days"), which will allow the project to release the updates soon after. There have been complaints in the past about updates that didn't exactly track the upstream RHEL release (i.e. changes for CentOS 5.5 that are not in RHEL 5.5), but doing so in previous releases (e.g. the 5.4 to 5.5 transition) "was the right thing to do" and when there is a "serious threat to user deployed machines, we would do it again", he said.
There has been some discussion of the problem on the centos-devel mailing list, with former CentOS developer Dag Wieers being particularly critical of the delays. He is concerned that users are being misled: "I don't think most of the users ever expected to be without security updates for 10 weeks or more when choosing CentOS, and that is an important characteristic." Singh and others agree that there are things that the project could be doing better, but do not see this as the right time to address those problems. As Singh puts it:
On the other hand, we can just get this done out of the door and then look at process engineering for the future. We are better, stronger as a group with a much larger contributor base than ever before - I see no reason why we could not strengthen that even further and split the roles out.
As part of that discussion, though, Singh muddies the waters further about which kinds of security fixes are actually being considered for CentOS 5:
But the reality seems to be rather different, as all manner of vulnerabilities are still languishing in the CentOS 5 tree.
It is a difficult situation for the project. It must necessarily trail the Red Hat releases, and keeping up with security updates while trying to push two releases out is difficult. Doing so would likely push back the releases even further. On the other hand, though, CentOS users may well be unaware that there have been potentially significant updates while they wait for CentOS 5.6. Unless those users follow the RHEL update announcements, they don't even know that there are vulnerabilities they may need to be aware of.
While there are no guarantees about security updates for CentOS (or any other community distribution for that matter), enterprise distribution users tend to expect regular updates, without significant, somewhat arbitrary, gaps. The biggest problem here is really one of communication as the CentOS team should try to make it widely known that security updates are being held back. It probably also makes sense for the project to try to figure out a way to keep up with the update stream even in the point release gap.
Another alternative would be to put CentOS 6 on hold, while focusing on CentOS 5.6. There are, after all, no CentOS 6 users yet, while CentOS 5 has many. It would also be nice to see some of the companies that benefit from CentOS (like various hosting providers, for example) put some effort into helping the project. Those companies are getting an awful lot from CentOS without, visibly at least, putting much back in.
The prohibition against taking more than very small quantities of liquids or unguents on planes is demonstrably ludicrous. It started as one of those "Look at us, we're taking decisive action" displays, the ones designed to cause maximum inconvenience to the public in order to make the dimwitted Dundridges who rule our lives feel important and look busy.
From this perspective, the purported details of the attack on HBGary - a horribly vulnerable, obscure CMS; unpatched internal systems; careless password reuse across corporate systems and Twitter or LinkedIn; and trivial susceptibility to e-mail phishing - are a truly fascinating detail. These tidbits seem to imply either extreme cynicism of their staff... or an [unbelievable] level of cluelessness. And from a broader perspective, both of these options are pretty scary.
|Created:||February 22, 2011||Updated:||February 23, 2011|
|Description:||From the Ubuntu advisory:
Sergey Nizovtsev discovered that Aptdaemon incorrectly filtered certain arguments when using its D-Bus interface. A local attacker could use this flaw to bypass security restrictions and view sensitive information by reading arbitrary files.
|Created:||February 21, 2011||Updated:||February 23, 2011|
|Description:||From the CVE entry:
awstats.cgi in AWStats before 7.0 accepts a configdir parameter in the URL, which allows remote attackers to execute arbitrary commands via a crafted configuration file located on a (1) WebDAV server or (2) NFS server.
|Created:||February 23, 2011||Updated:||April 8, 2011|
From the Ubuntu advisory:
It was discovered that Bind incorrectly handled IXFR transfers and dynamic updates while under heavy load when used as an authoritative server. A remote attacker could use this flaw to cause Bind to stop responding, resulting in a denial of service.
|Created:||February 22, 2011||Updated:||April 11, 2011|
|Description:||From the Fedora advisory:
Dylan Alex Simon discovered and reported a directory traversal flaw in the way Gitolite restricted access to admin defined commands ("ADC"). An authenticated attacker could execute arbitrary code with privileges of Gitolite server user using specially crafted command name.
|Package(s):||java-1.6.0-openjdk||CVE #(s):||CVE-2010-4448 CVE-2010-4450 CVE-2010-4465 CVE-2010-4469 CVE-2010-4470 CVE-2010-4472 CVE-2010-4471|
|Created:||February 17, 2011||Updated:||July 22, 2011|
From the Red Hat advisory:
A flaw was found in the Swing library. Forged TimerEvents could be used to bypass SecurityManager checks, allowing access to otherwise blocked files and directories. (CVE-2010-4465)
A flaw was found in the HotSpot component in OpenJDK. Certain bytecode instructions confused the memory management within the Java Virtual Machine (JVM), which could lead to heap corruption. (CVE-2010-4469)
A flaw was found in the way JAXP (Java API for XML Processing) components were handled, allowing them to be manipulated by untrusted applets. This could be used to elevate privileges and bypass secure XML processing restrictions. (CVE-2010-4470)
It was found that untrusted applets could create and place cache entries in the name resolution cache. This could allow an attacker targeted manipulation over name resolution until the OpenJDK VM is restarted. (CVE-2010-4448)
It was found that the Java launcher provided by OpenJDK did not check the LD_LIBRARY_PATH environment variable for insecure empty path elements. A local attacker able to trick a user into running the Java launcher while working from an attacker-writable directory could use this flaw to load an untrusted library, subverting the Java security model. (CVE-2010-4450)
A flaw was found in the XML Digital Signature component in OpenJDK. Untrusted code could use this flaw to replace the Java Runtime Environment (JRE) XML Digital Signature Transform or C14N algorithm implementations to intercept digital signature operations. (CVE-2010-4472)
Note: All of the above flaws can only be remotely triggered in OpenJDK by calling the "appletviewer" application.
|Package(s):||java-1.6.0-sun||CVE #(s):||CVE-2010-4422 CVE-2010-4447 CVE-2010-4451 CVE-2010-4452 CVE-2010-4454 CVE-2010-4462 CVE-2010-4463 CVE-2010-4466 CVE-2010-4467 CVE-2010-4468 CVE-2010-4473 CVE-2010-4475|
|Created:||February 17, 2011||Updated:||July 22, 2011|
From the Red Hat advisory:
CVE-2010-4475 JDK unspecified vulnerability in Deployment component
CVE-2010-4473 JDK unspecified vulnerability in Sound component
CVE-2010-4468 JDK unspecified vulnerability in JDBC component
CVE-2010-4467 JDK unspecified vulnerability in Deployment component
CVE-2010-4466 JDK unspecified vulnerability in Deployment component
CVE-2010-4463 JDK unspecified vulnerability in Deployment component
CVE-2010-4462 JDK unspecified vulnerability in Sound component
CVE-2010-4454 JDK unspecified vulnerability in Sound component
CVE-2010-4452 JDK unspecified vulnerability in Deployment component
CVE-2010-4451 JDK unspecified vulnerability in Install component
CVE-2010-4447 JDK unspecified vulnerability in Deployment component
CVE-2010-4422 JDK unspecified vulnerability in Deployment component
|Created:||February 21, 2011||Updated:||May 17, 2011|
|Description:||From the Debian advisory:
|Package(s):||openafs||CVE #(s):||CVE-2011-0430 CVE-2011-0431|
|Created:||February 17, 2011||Updated:||February 23, 2011|
From the Debian advisory:
CVE-2011-0430: Andrew Deason discovered that a double free in the Rx server process could lead to denial of service or the execution of arbitrary code.
CVE-2011-0431: It was discovered that insufficient error handling in the kernel module could lead to denial of service.
|Created:||February 21, 2011||Updated:||February 23, 2011|
|Description:||From the Mandriva advisory:
Directory traversal vulnerability in Django 1.1.x before 1.1.4 and 1.2.x before 1.2.5 on Windows might allow remote attackers to read or execute files via a / (slash) character in a key in a session cookie, related to session replays.
|Created:||February 17, 2011||Updated:||April 19, 2011|
From the Debian advisory:
It was discovered that telepathy-gabble, the Jabber/XMMP connection manager for the Telepathy framework, is processing google:jingleinfo updates without validating their origin. This may allow an attacker to trick telepathy-gabble into relaying streamed media data through a server of his choice and thus intercept audio and video calls.
|Package(s):||webkitgtk||CVE #(s):||CVE-2010-4492 CVE-2010-4493 CVE-2011-0482 CVE-2010-4199 CVE-2010-4578 CVE-2010-4042|
|Created:||February 18, 2011||Updated:||August 23, 2011|
|Description:||From the CVE entries:
Use-after-free vulnerability in Google Chrome before 8.0.552.215 allows remote attackers to cause a denial of service or possibly have unspecified other impact via vectors involving SVG animations. (CVE-2010-4492)
Use-after-free vulnerability in Google Chrome before 8.0.552.215 allows remote attackers to cause a denial of service via vectors related to the handling of mouse dragging events. (CVE-2010-4493)
Google Chrome before 8.0.552.237 and Chrome OS before 8.0.552.344 do not properly perform a cast of an unspecified variable during handling of anchors, which allows remote attackers to cause a denial of service or possibly have unspecified other impact via a crafted HTML document. (CVE-2011-0482)
Google Chrome before 7.0.517.44 does not properly perform a cast of an unspecified variable during processing of an SVG use element, which allows remote attackers to cause a denial of service or possibly have unspecified other impact via a crafted SVG document. (CVE-2010-4199)
Google Chrome before 8.0.552.224 and Chrome OS before 8.0.552.343 do not properly perform cursor handling, which allows remote attackers to cause a denial of service or possibly have unspecified other impact via unknown vectors that lead to "stale pointers." (CVE-2010-4578)
Google Chrome before 7.0.517.41 does not properly handle element maps, which allows remote attackers to cause a denial of service or possibly have unspecified other impact via vectors related to "stale elements." (CVE-2010-4042)
Page editor: Jake Edge
Next page: Kernel development>>
Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds