Josh's Blog

The biggest security story from last week would have to be news that the life of Firefox 1.5 is being extended by upstream until mid may:
http://www.mozillazine.org/talkback.html?article=21543

The Mozilla project is planning to stop providing official updates for the 1.5 Firefox branch. They of course want to put their development effort into the 2.0 branch. The current plan for Red Hat and Fedora is to roll security patches into the 1.5 branch. Several distributions are going to work together to keep the 1.5 branch maintained with security patches since there is great interest in keeping 1.5 maintained for the immediate future. Chris Aillon explains this in a blog posting:
Mozilla Corp. to work more closely with Linux distributors.

This action shows a huge strength regarding Open Source software and security maintenance. When a closed source application is distributed, you have to run whatever version the author wishes you to run. If an application has the source available, and the will exists, a technically unsupported version can live on.

There is remarkably little to write about this week. This time of year is usually pretty slow from a security point of view. This is always nice though as it gives us plenty of time to deal with some of the lower priority flaws that get pushed back during times of heavy load.

Risk report: Two years of Red Hat Enterprise Linux 4

Mark Cox wrote an interesting article looking at the last two years of security flaws in Red Hat Enterprise Linux 4. The information in this article should be rather interesting to anyone who tracks open source security flaws. There is not a lot of public analysis of open source security flaws. The article does focus on Red Hat Enterprise Linux 4, but the trends represented will apply to any Linux distribution.


Macbook hacked at cansecwest.

Apple's OS X is currently gaining attention in the security world. Historically people have considered OS X to be very secure and mostly virus and hack free. This is starting to change as researchers have been paying attention to the Mac lately. Part of this is probably the challenge it presents. Those of us in the Linux world have been enjoying a similar situation. There is little fear of viruses, and as long as one applies security updates, there isn't much fear of being compromised.

There are many people who will argue that the real reason for this is that Linux is more secure by design. I believe it's a combination of things. Historically Linux users have been a bit more savvy, this is starting to change. In the past, the desktop was also very simple. This too is changing. As Gnome and KDE gain functionality, they also gain more security flaws. For example, the fact that the desktop will display a thumbnail of many different file types gives an attacker a doorway into a system. They of course need to convince a user into downloading a file, but as we've seen from many viruses, this is no as hard as it sounds. I hope that various technologies such as SELinux and Exec-Shield will help keep most of the trash away, the human factor cannot be fixed as easily. As long as people are willing to open attachments, and visit random web sites, viruses will exist. As a friend of mine used to say "We're OK until the toaster people start using it." The "toaster people" are the normal people confused by the knob on their toasters

Remarkably little happened this week in the security universe. I wonder if this is the result of the fabled Microsoft Patch Tuesday, and researchers not wanting to lose attention to the pending flood of stories about all the windows patches. The general idea behind this is that rather than release updates when they're ready, Microsoft will hold them until the second Tuesday of every month. I'm honestly not sure how I feel about this, but in general it doesn't work in the open source world. We generally have little control over when many security updates are released. If an open source project wants to release an update on a Sunday night, there is nothing stopping them from doing that. This of course isn't ideal for most people, but it's one of the many issues with the rather chaotic world of open source security updates.


This story from Bruce Schneier's blog made me immediately think of open source:
U.S. Government Contractor Injects Malicious Software into Critical Military Computers.
This sort of thing probably happens more than anybody will ever admit, but it's likely a lot harder to pull of when your development is conducted in an open and transparent manner. It's also nearly impossible to prove in a closed source system. Even if such a flaw is found in a closed source system, it would not surprise me if many vendors would try to keep such information hidden. It's certainly not in the best interest of a vendor to let news of a back door go public.

On this note though, what do projects do to stay secure? Is there anything preventing a disgruntled project member from causing harm (even if it is found immediately)? Apache.org had a slightly similar experience with this some time ago:
Apache.Org compromise report, May 30th, 2001
They handled it about the best any project could.


A memory leak flaw in FreeRADIUS was found. The flaw itself isn't really noteworthy, but it does give me a good opportunity to note that there is often a fine line separating old fashioned bugs and security flaws.

Many software applications contain memory leaks and it's usually not a big deal. I don't suggest one should ignore a memory leak since it is a bug, but not all memory leaks are security flaws either. However they are serious problems with long running applications such as daemons. There are a number of bugs that can be considered a security flaw given the right circumstances. One of the jobs of the security team is to investigate these bugs and sort the chaff from the wheat. Another favorite is a user assisted crash. If a remote attacker can make something like FreeRADIUS crash, it's a security flaw. If a remote attacker can make Firefox crash, we call it a "don't do that again" bug.


Mark Cox had a most interesting blog posting this week: Information Sources. Most people don't really worry about where security flaws come from, but it is most interesting when you're on of the lucky people who have to try to make sense of all this madness. It's nice to know this since we know that it's worth the effort to maintain a healthy relationship with upstream projects and various researchers. It is a goal of the Red Hat Security Response Team to work with anyone who approaches us with a flaw. The goal is to keep the users as safe as possible, which can occasionally make our lives a bit painful when dealing with difficult projects and researchers, but no doubt it's well worth it.

Last week I asked what people think about me not displaying a list of all security flaws fixed each week. I got one reader who was interested in seeing this list, but in general I received little feedback. Given there are already good places to find this information, I think duplicating it here would be a bit of a waste.

Updates for Red Hat Enterprise Linux are best viewed from the Enterprise Watch List archives, or Red Hat Network.
Updates for Fedora can be found in Fedora Weekly News

Fedora Security Response Team
The Fedora Security Response Team is slowly taking shape. The team will be responsible for all Fedora security updates in Fedora 7 and beyond. Creating a security team is not a trivial task, and I believe it's best done in an organic manner. Anytime anyone tries to create a process around anything regarding security, it often ends up being overly complex. By keeping things simple from the start and adding process as needed, it's more likely the security team will be a success. If you have an interest in helping the Fedora Security Response Team, more information can be found here.

krb5
The biggest update last week would have to be Kerberos. There were three flaws fixed, but the really scary one was a flaw in the MIT krb5 telnet daemon. The telnet daemon shipped in krb5 allows for encrypted telnet sessions. As most people know, it is unwise and unsafe to use unencrypted telnet to connect to a remote machine. The flaw could allow a remote user to login as root, without a password. Anytime there is a remote flaw such as this, it's rather scary given the potential for a worm attack.

I've been asked to write a security blurb for Fedora Weekly News. The basic idea is that they will be mostly syndicating what I write here, just with a Fedora slant, and they get it a day early. I see no problem with this and honestly, I'm all for anything that will help make Fedora better.

I decided to boycott my computer yesterday as I can't take how inane April 1 has become. It's probably nothing new, but it's really started to annoy me these last few years, so today the Security Week in Review comes to you +1 day.

Last week saw the end to the Month of PHP Bugs. As a whole is was mostly unexciting. I'm not a fan of any month of "something" projects. I think they're just people pandering to the press, but it doesn't really seem to work. Every month of something project has pretty much just fizzled out at the end with nobody really noticing. I suspect if they really wanted to pimp themselves to the press, releasing thirty advisories at once to a mailing list would gain far more attention (please note I don't think this is a good idea either).

So I've come to a crossroads with this weekly column again. I'm wondering if listing last week's security updates is of use given there are other places once can find this information without much effort. I'm thinking it may be more worthwhile to just comment on the various updates and flaws that deserve comment. I find that the hardest thing about writing a blurb each week is how to keep it interesting. I'm not going to list any security updates in this week's column. If anyone likes seeing them here, please leave a comment, and I'll bring them back. Additionally, if there is something you like or dislike about what you see, I'd love to hear from you.