Josh's Blog

So I got a new colo machine today. I was previously using a service called unixshell#, which was based on xen. In general I've had mostly good experiences with unixshell#, but I noticed that they were directing people to their new offering running on virtuozzo, TekTonic, with a price that's hard to pass up. For $15 a month I get

256MB Dedicated RAM
10GB Disk Space
Dual Processors
1.0 Mbit Unmetered (equiv. 320GB)
1 IP Address

So far I'm pretty happy. I've already noticed that the virtuozzo setup caps the disk IO. Normally this would be a bad thing as my performance on IO heavy tasks isn't great, but it also means that other users on the same hardware can't destroy my performance by running find. The best part of the whole thing was my unixshell# machine was magically migrated to the virtuozzo host, which took zero time on my part for this migration to happen.

I figured I'd give TekTonic my praises and let anyone looking for a decent inexpensive shared hosting colo a place to look.

This week would appear to be pretty tame given how few security updates there were. Fedora Core saw zero security update while Red Hat Enterprise Linux saw two. The most notable thing that happened this week was a bind update. I shall comment on that at the end.

Security Updates

• Adobe Acrobat Reader
  Fixed in Red Hat Enterprise Linux 3
  This Acrobat Reader update lagged the Red Hat Enterprise Linux 4 update by a week due to technical difficulties. Adobe decided that the new Reader will only work with gtk version 2.4 and higher. Red Hat Enterprise Linux 3 contains gtk version 2.2, which is obviously a problem. We weren't willing to leave our users high and dry on this issue, so after a great deal of effort, Kristian managed to package a special gtk 2.4 package which is used only by the new Acrobat Reader packages.
  
  This is one of the annoying issues with closed source software. We are beholden to Adobe and the choices they make. If Acrobat Reader was an open source application, we could have simply backported the security fix and built updated packages.
  
  
• gtk2
  Fixed in Red Hat Enterprise Linux 4
  A bug was found in the way gtk2 processes bad image data. There isn't any potential for arbitrary code execution, it's just a crash. Most things that use gtk2 can crash without causing much trouble for the user. We like to think of those crashes as "don't do that again" class of bugs. The biggest problem with this flaw is Evolution. Evolution seems to think that it's a neat idea to reload the same message you were reading when recovering from a crash. As any clever person may guess, if the mail message you opened is the reason for the crash, Evolution will never restart. This means that an evildoer could send a mail message to an evolution user that would make it difficult to recover from.

A bind update was released on 2007-01-25. The new BIND fixes two security flaws, ISC has provided minimal details regarding the flaws. The way ISC handled these flaws was done rather irresponsibly in my opinion. The advisories and their response was very lacking. The advisories were not well written and did not contain useful details. I logically mailed ISC with questions about the update and if they could provide details about the flaws. I've found that it's usually easier for upstream to provide analysis for flaws since they are the experts. Almost all open source upstream projects are very responsive and helpful when dealing with security updates. ISC however has not been helpful or responsive. I did not receive a response for several days, and the response I did get asked "Did you even perform a recursive diff of BIND 9.3.3 vs BIND 9.3.4 ..."

This response is most disheartening. I once believed ISC was a stand up organization, but the past few BIND updates we've seen have me wondering if this is true. ISC is very unwilling to engage the community in a meaningful and helpful manner. This worries me greatly since there are a number of ISC projects that are widely used as part of the critical infrastructure of the Internet. Hopefully my experiences have been flukes, but I'm beginning to think not.

This week was rather slow from a security standpoint. This was a good thing as it game me some time to catchup on some things that were lagging behind. One of the more interesting things I did was get a webcam and used ekiga for some video conferencing. It's still a bit clunky I thought, but in general very usable.

Security Updates

• kernel
  Fixed in Red Hat Enterprise Linux 2.1, FC6
  While there were kernel update for FC6 and RHEL2.1, they have virtually nothing in common. A kernel update for any version of Red Hat Enterprise Linux has rather strict process for including a fix. This is done because of issues such as a stable ABI and having to maintain the kernel for 7 years. The Fedora kernel update follows upstream as closely as possible, this is by design, and can be an advantage when trying to support new hardware.
  
  
• w3m
  Fixed in FC5, FC6
  
  
• fetchmail
  Fixed in FC5, FC6
  
  
• squirrelmail
  Fixed in FC5, FC6
  This squirrelmail update fixes a cross site scripting flaw that was discovered in 2006. We usually consider cross site scripting flaws to be of moderate severity. Ideally we like to sit on moderate issues for a short period of time so if another flaw is discovered in squirrelmail we can fix them all at once, instead of many little updates.
  
  
• squid
  Fixed in FC5
  The flaw fixed in this update, CVE-2007-0247, also affects FC6. That update should come out in the near future.
  
  
• ed
  Fixed in FC5, FC6
  Yes, a security update in ed. I can't help but keep think that Ed is the standard text editor. It's a minor temporary file flaw that's being fixed. I think it's noteworthy that ed is still packaged even though it's incredibly old.

A cacti flaw has been brought to my attention this week. I've heard from multiple sources that there is active exploitation of a rather foul cacti hole. If you're a cacti user, you will want to apply these patches:
http://www.cacti.net/download_patches.php?version=0.8.6i.
This is a fine example of why there are serious advantages to running things that are packaged by your distribution. Usually the various distribution security teams will know about and fix security flaws before they are widely exploited.

I've been thinking about the format of my Security Week in Review weekly posting. After some useful input from Mark I've decided to slant this toward Fedora and Red Hat issues. I'll make the occasional general comment if it permits, but I think there is more value if I narrow my focus. The most notable addition will be noting last weeks security updates released from Fedora and Red Hat.

Security Updates

• xorg/XFree86
  Fixed in FC5, FC6, and Red Hat Enterprise Linux 2.1, 3, and 4.
  iDefense reported several integer overflow flaws in the DBE and Render extensions of X.org and XFree86. This flaw affected all versions of XFree86 and X.org shipped in Fedora Core and Red Hat Enterprise Linux. A flaw of this type could allow a local user to leverage this flaw to elevate their privileges to 'root'.
  
  
• libgsf
  Fixed in Red Hat Enterprise Linux 3 and 4.
  A heap overflow flaw in libgsf was fixed for Red Hat Enterprise Linux. This is not a new flaw, it was discovered in 2006, but it was rated moderate by the Red Hat Security Response Team. There are more security flaws than there is time to fix them. One of the important pieces of keeping a distribution up to date on security issues is to rank them all by priority and fix them in order of importance. That means that a fix such as this one, which is of minor severity, will get pushed onto the back burner when something like the X flaws are discovered.
  
  
• acroread
  Fixed in Red Hat Enterprise Linux Extras 4.
  Red Hat ship the Adobe Acrobat Reader as part of Red Hat Enterprise Linux Extras. Acrobat Reader is a closed source application which only Adobe has access to the source code of. There are several unique challenges when releasing updates for a closed source application such as the Acrobat Reader. We must rely on the analysis of the flaws that Adobe gives us, and use the new binaries provided. Rarely will an Acrobat Reader update only fix security issues. New features and various bugs are fixed. This can cause serious problems when updating these packages. In this instance, the new Acrobat Reader will not run on Red Hat Enterprise Linux 3. We're currently working on making this happen, but it causes far more pain than we would normally see with our usual open source updates. I'd say in this instance, open source has rather obvious advantages.
  
  
• flash-plugin
  Fixed in Red Hat Enterprise Linux Extras 3 and 4.
  The Adobe Flash Player was also updated for Red Hat Enterprise Linux Extras. This was an instance of a new binary package (see the acroread explanation above), and a moderate flaw (the libgsf explanation). The update wasn't painless, but wasn't terribly painful either.
  
  
• wget
  Fixed in FC5 and FC6.
  Wget was updated to fix a denial of service flaw when connecting to a malicious FTP server. This is considered a low severity flaw, and while it also affects Red Hat Enterprise Linux, we won't be releasing an wget update just for this flaw. We try to wait and fix several bugs at a time rather than just one low issue here and there.
  
  
• krb5
  Fixed in FC5 and FC6.
  These flaws did not affect the versions of krb5 shipped in Red Hat Enterprise Linux.
  
  
• xterm
  Fixed in FC5 and FC6.
  
  
• avahi
  Fixed in FC5
  
  
• mono
  Updated in FC5 and FC6

My biggest gripe of the week would be the Month of Apple Bugs project finding a multi-vendor PDF flaw. They claim the flaw is in the PDF spec itself. The most annoying part of their analysis is they show an xpdf debugging session on Fedora Core 5, and claim the flaw is exploitable. They fail to mention that the segfault is caused by an infinite recursion flaw. Infinite recursions flaws are not exploitable to allow arbitrary code execution, they will only crash the application. One of the goals of any security response team should be to add value by analyzing information such as this and determining when it's untrue.

It's been quite some weeks since I published a week in review post. The holiday season was mostly quiet, which was wonderful in general.

Mozilla
The most notable thing I found worth mentioning over the holidays was a security update of the Mozilla products. The pace at which the Mozilla project releases can be trying at times, but after reading Internet Explorer Unsafe for 284 Days in 2006 and reflecting on the matter, I think the quick pace of updates from the Mozilla project is the right thing to do. All web browsers have bugs, the horrible complexity along with the new features added to the browsing experience mean that the number of security flaws probably won't be decreasing in the near future. By sitting on security flaws, even embargoed flaws, users are placed at an unneeded risk. There is a great deal of well known interest from the computer underworld in browser exploits. There is no excuse for not fixing known flaws.

Opera
Opera patched in secret. It seems that the Opera folks tried to sneak in two critical fixes without telling anyone. The Opera 9.10 changelog doesn't note that there are any substantial security fixes in the update, but it seems they fixed two critical flaws.

I initially thought about commenting on this event as a plug for open source software and its transparency, but I then got to thinking about what would happen if Mozilla did this. It's likely nobody would really notice as there is often hundreds of bugs fixed in any given Firefox release. I think this more a matter of accountability. Opera is a company that is trying to make money. It's in their best financial interest to not have security flaws in their products. They probably think they have something to gain by quietly fixing security flaws, which I'm certain they've changed their minds after the bad press they're getting for this. I would be surprised if security updates affect the Mozilla Foundation revenue stream in any way. It's more likely that the brutal honesty of the Mozilla project regarding security flaws is proving to be positive. When there is a new Firefox release, it's mostly a non story as everything is out in the open for anyone to look at. There's no sneaking around happening that makes a good story.

OpenOffice.org
Speaking of sneaking around, it seems there was some thought that the recent OpenOffice.org update was a bit sneaky. There was bit of attention brought to this issue since the bug was reported in October, yet the full extent of the flaw wasn't known until January 2nd. I will admit that the issue could probably have been handled better, but the upstream project wanted to keep the details under wraps until they had a chance to release version 1.1.5. That's pretty much the story, it's not terribly exciting.

Various Thoughts

I ran across this story the other day: Poll: Most Consumers Don't Trust Their Security Software. A quote from that story has me rather bothered

"It's also our job to regularly communicate with our customers regarding their level of security, in a way that is meaningful to them, so that they know how secure they are."

When you're handling security for an end user, they are either secure or not. It's not a scale, it's a boolean value. I often wonder if this is where most of the high profile security vendors have gone astray. They now spend more time justifying their security solutions than just making a high quality solution that just works.

This article has me wondering: Rift Widens Over Bug Disclosure. While these month of whatever projects can cause me a bit of pain, so far they've been pretty easy on the open source world. I'm always glad that there are people investing time into security research, but part of me thinks not alerting the vendor in any way isn't right either. I can understand going public with a flaw after a reasonable period of time, but just blindly hitting vendors with a bug a day for a month is a bit harsh. I think the best way for me to justify this is to ask what I would do in such a situation. If I knew of 30 bugs, each of which have security potential what would I do with them? I'm confident I wouldn't blindside vendors with them. How to report that many flaws could present a challenge though. I suspect the real culprit here is researchers looking for their 15 minutes of fame. If a researcher reports that many bugs responsibly and have their names plastered over many security advisories, they could be in store for far more than 15 minutes of notoriety.


Well, that's all for this week. See you next time.