Recently we were greeted by Heartbleed, a bug in software used by web sites to encrypt data. Now we hear of a flaw in Internet Explorer (IE) that allows a malicious web site to run any program it desires on your computer. One can debate which is the more serious, but both can be devastating. In light of the risks from the IE bug, the Department of Homeland Security (DHS) has recommended that people not use that browser until it is patched. However, there’s a serious problem with that advice: Windows XP is susceptible to the IE vulnerability, and Microsoft discontinued support for that OS version last month.
Because the Heartbleed code was in an Open Source component (that is, a piece of software whose source code is openly available), a fair amount of discussion has focused on whether distributing security-related code as Open Source increases or decreases the risk of such bugs. That’s indeed an interesting debate. I happen to come down on the side of its decreasing the risk, but the DHS recommendation reveals a completely different security problem in using programs that are not Open Source.
For Heartbleed the correction to the source code was made publicly available as soon as the vulnerability was discovered, so anyone with the needed skills could repair the bug themselves in their own system. More importantly, they could also distribute patches to people who did not have such skills. As a result, key sites were fixed almost immediately, and nearly everyone was able to have their systems updated within a week.
In the current situation with Internet Explorer, the software is highly proprietary. Although the repair is likely very simple (most of these are) only Microsoft has the necessary access to the source code. No matter how skilled a person might be, they will not be able to correct the defect. What this means is that everyone is at the mercy of Microsoft’s schedule. Will the company issue a patch immediately, or wait until “Patch Tuesday”? And what’s going to happen to XP users, who still form a significant proportion of the population?
The point is that none of us can do anything other than wait for Microsoft and see what they will or won’t do, which is the complete opposite of the situation with Heartbleed. This is not meant as a criticism of Microsoft, but as a “fact of life” for proprietary software.
No doubt the debate on the merits of Open Source versus proprietary software, particularly in terms of preventing bugs and security holes, will continue indefinitely. But prevention is not the complete story. Rapid response and correction are critical when problems are detected, and the Heartbleed experience illustrates an important advantage of the Open Source approach. Indeed, it was just such an advantage that inspired Richard Stallman to establish the Free Software Foundation nearly thirty years ago. He specifically chose the term “Free Software” instead of “Open Source” because it emphasizes people’s freedom to control their own destinies when it comes to software. In the political sphere, freedom and security often conflict, but in the software arena they are very much compatible.
About Richard Kenner
Richard Kenner is a co-founder and Vice President of AdaCore. He was a researcher in the Computer Science Department at New York University from 1975 through 1998. During that time, he worked with the SETL Project, a research project in high-level programming languages, the PUMA Project, which designed and built an emulator for the CDC 6600 in the late 1970’s, and for many years with the Ultracomputer Project, which did research on highly-parallel computer systems. At Ultra, he worked on hardware design, VLSI design, and compilers. As part of the latter work, he was the maintainer of the GCC compiler (on which the GNAT technology is based) for the Free Software Foundation for the 2.5.x through 2.8.x releases. He published papers both on compiler design and VLSI design of a switching network for Ultra and was the designer of the interface between the GNAT front end and GCC.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.