Changing the Notification Process, 2005-02-23
Developers have the opportunity to offer better vendor security procedures and notifications in an open-source world.
“
"The slower and more convoluted this process is, as many projects are finding today, the more likely it is that something is going to get missed. "
”
Perhaps the first question should be why I think we need to improve the state of Unix, BSD and Linux security. As both the Unix and open-source worlds grow and converge, the small community of like minded people becomes larger, and simply relying on personal contacts within the community is no longer feasible. I don't believe that enough is being done and I also think that as time goes on, the weaknesses in the system will become more apparent. I believe that traditional open-source has simply gotten by in the chaotic world of security not because it is inherently secure (as some of my previous columns have pointed out), but rather because so many of the closed source products were found to be so bad. In other words, anything that dealt with security in a more transparent and reactive manner than closed source looked so much better by comparison.
Saying that we are better than the other guy, sometimes while pointing and laughing, is never the best approach to security, but lately it's getting far harder to do that. The 95 pound weaklings on the beach are bulking up, and the Unix and open source players are all looking pretty much the same. I've got a couple ideas on how to turn this trend around, but it will take some work to get there.
My idea doesn't involve getting people to write better code, because if that were my focus I'd be giving seminars instead of writing this column. I am, however, going to suggest a framework for all open-source projects that can help with the process of identifying, notifying, coordinating, and fixing vulnerabilities when they are found. The slower and more convoluted this process is, as many projects are finding today, the more likely it is that something is going to get missed.
If we want the open-source world to continue to grow outside of its traditional niche of hackers and academics, and if we want others to actively choose open-source solutions, security vulnerabilities cannot be ignored, lost, or hidden. As Unix continues to depend more and more on open-source software for functionality, the problem becomes more significant. This is further complicated by the nature of open-source development and distribution.
Here is a situation: suppose you are an emerging security researcher, and you discover a security vulnerability in the kernel distributed with Redhat Enterprise Linux. Should you email Linus Torvalds? Should you post a message to the Linux Kernel Mailing List (LKML), or perhaps pop on an IRC channel and report the bug? Maybe you decide tol email Redhat? Or should you go buy SuSE Linux, download and install Gentoo, and try out different kernels to find out if they are also vulnerable? Maybe the problem is related to a patch to the main kernel tree that Redhat is using, while other vendors and the vanilla kernel aren't affected. Who else is distributing that patch? Who ultimately is responsible for fixing it, and how do I discover who this person is?
What I am proposing is that a group with a vested interest in promoting and guiding open-source development (the Open Source Initiative (OSI) leaps to mind), create an "Open Source Secure" stamp of approval. To receive it, certain criteria have to be met in the project.
- security@projectname.tld must be a valid email address. It routes to a person or team who is responsible for researching, coordinating, and notifying others about vulnerability fixes. This is critical. Vulnerability notification has to be handled quickly and responsibly.
- The project would need to have a documented vulnerability handling procedure that includes who is notified, what is the timeline for acknowledgement of communication, and when or how the vulnerability communicated to other projects that may be distributing the vulnerable software.
- The source distribution has some mechanism to verify that the source files have not been tampered with. This mechanism may involve PGP, or MD5 and SHA hashing (use both, it's better).
- The verification "key" for the source-assurance must be kept off-site, to help ensure that if the file repository is compromised, the attacker doesn't simply have to replace the MD5 sums with a new one.
In addition to the two criteria above, I am suggesting that a database be setup that allows a project to track all the other open source projects that they distribute or depend on. This allows the project to notify all "customers" that there is an upcoming fix. This framework also can allow the "customer" some lead time to prepare for QA testing that will be required.
An example can highlight what I am suggesting. Suppose I develop a workforce management application that relies on the open-source Jabber server for its underlying communication. My open-source project is distributed by most of the Enterprise Linux distributions and is available as a port to most BSD applications. I also distribute a Solaris version with a support contract.
Now suppose someone discovers a vulnerability in Jabber, so they email security@jabber.org. The Jabber security contact evaluates and notifies everyone in the OSI Secure database that is known to distribute or rely on the jabber server, telling them that a vulnerability fix is expected within two days. I would receive this email because I previously set-up my settings to receive security updates from this project.
My project security contact receives the notification, and in turn I notify my QA team that we will need to expedite testing and the release of a new version of my workforce management application. In addition, I notify my "customers" in the OSI Secure database that a new version of my software MAY be forthcoming with a further update in three days, once we have evaluated the changes made by Jabber.
From the perspective of a vendor distributing other projects, choosing to distribute only projects that are part of this framework can help ensure that users are less exposed to risks from vulnerability handling problems. The criteria for membership in this group must not be too onerous, because I believe it important that one should maintain the diversity that open-source software currently enjoys. A framework such as this will reward projects that take security seriously.
These are suggestions for a place to start. There may be functional and ideological issues that are inherent in my suggestions, not the least of which are the legal ramifications of certifying a security response mechanism in a project consisting of volunteers. However, this is certainly for the benefit of the community and its rapidly expanding user base. Change can be hard, but it is usually worth it.
