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.
