The recent announcement of a 13-year old security flaw found in an Open Source security library has renewed the debate between open source and closed source software. The library, crypt_blowfish, allows for fast two-way password encryption. The flaw introduces the potential for passwords to be easily compromised and affects PHP and a number of Linux distributions that include the crypt_blowfish library. As with most security bug announcements both the Linux/Open Source and Microsoft/Closed Source supporters began pointing fingers at each other on several news sites and blogs, with the occasional troll tossing in a flaming comment just to keep emotions high. Unfortunately this type of debate rarely does anything to move the industry or community closer to more secure software deployments. In handling aged security flaws such as this it is important to put aside emotion and focus on the issue. Security issues involving a broadly deployed code base require […]

The recent announcement of a 13-year old security flaw found in an Open Source security library has renewed the debate between open source and closed source software. The library, crypt_blowfish, allows for fast two-way password encryption. The flaw introduces the potential for passwords to be easily compromised and affects PHP and a number of Linux distributions that include the crypt_blowfish library.
As with most security bug announcements both the Linux/Open Source and Microsoft/Closed Source supporters began pointing fingers at each other on several news sites and blogs, with the occasional troll tossing in a flaming comment just to keep emotions high. Unfortunately this type of debate rarely does anything to move the industry or community closer to more secure software deployments.
In handling aged security flaws such as this it is important to put aside emotion and focus on the issue. Security issues involving a broadly deployed code base require management and cooperation, not debate. As part of managing the issue there are several key issues that need to be addressed in order to mitigate the flaw and close the gap between zero-day announcement and the patching of end-user systems.
First, and most important, is to understand how a security flaw such as this was able to remain undetected for such a long time. Whether open or closed source code is not the point here; there are developers somewhere that produced, tested, and maintained the code base. Is this particular flaw a very complex issue that was not easily found or a simple lack of due diligence in testing the code base against standard practices and procedures? This is the type of Root-Cause Analysis (RCA) required to determine corrective actions and to ensure the same types of issues do not occur again.
Once a root cause has been determined and correction measures determined the next issue is arguably the most important: creating the necessary fix or patch and providing the solution to the deployed user base. It is at this stage that the chess game begins between software developers and those that exploit vulnerabilities in their code. While the developers are moving to provide the community or industry with a solid fix for the flaw the other side is working to exploit that flaw as quickly as possible. Time becomes an issue here.
The final issue is mass-deployment of the fix/patch and verification of installation. This is usually a lengthy process and inevitably not every system is patched. There are often headlines and breaking news stories resulting from unpatched systems being accessed or exploited, and it seems likely that this will always be the case-especially on a very widely deployed code base such as that of Linux or a Microsoft OS.
In the case of this latest security issue, without question the developer did the right thing and reacted properly with the immediate and public notification of the issue and the fix. As many would agree the Open Source model and community seems to do very well at rapidly mitigating security issues once they are found (this case being no excepting, with the developer communicating the issue and the fix within hours of finding the bug.)
The fact that this issue has been in existence for so many years-in publicly accessible and reviewed code-does call into question the development and testing process used to ensure the code base was security. However, the important take-away here isn’t in placing blame but in developing new development and testing procedures to ensure a more secure code base is released.
How rapidly the patch will be deployed is yet to be seen, but given the past response of the Open Source community to security issues it will likely be a very rapid deployment. The potential fallout from the number of systems running the crypt_blowfish library that will inevitably not be patched, however, is something that will haunt system admins and security experts for years to come.
What both sides of the open/closed-source debate need to come to terms with is that security issues that impact one side will inevitably impact the other, and with the continuing growth of the Internet it will inevitably impact us all.