Security and Source Code Access: Issues and Realities Steven B. Lipner Microsoft Corporation
[email protected]
Abstract This position paper addresses some of the benefits and drawbacks for security of open access to source code. After a discussion of alternative models for open access to source code, the paper reviews the positive and negative implications of each for system security. The paper concludes that source code review can have real benefits for security, but that those benefits are not realized automatically, and that some source code access models introduce significant drawbacks.
1. A matter of definition In discussions of the benefits and drawbacks of source code access for security, it’s worth considering that there are at least three levels of openness that come into play, each with its own benefits, drawbacks, and peripheral issues: 1. Public disclosure of algorithms and protocols 2. Public disclosure of source code 3. Public or open contribution of source. Each of these levels of openness has its own implications for security. Each also has associated costs that are often overlooked in discussions that focus only on benefits.
2. Disclosure of algorithms and protocols It is easiest to make a case for public review of the algorithms and protocols that underlie secure systems. The most frequently cited examples come from cryptography, where many flawed algorithms have been broken since the explosion of academic interest in cryptography. The development of security protocols by standards bodies – principally the IETF – has also seen clear benefits from openness. The down side of any open process for the development and review of security systems is that open review might reveal security flaws and render users of flawed mechanisms subject to attack. This argument is usually derided in the security community as “security through obscurity.” The claim that security through obscurity is a
0-7695-0665-8/00 $10.00 ã 2000 IEEE
Bad Thing has its roots in cryptography, where algorithms have historically been designed to resist even an adversary who knew the algorithm but not the keys used to protect specific data. There are really no compelling arguments against public disclosure of security algorithms and protocols. The case for such review is strengthened by the facts that security algorithms and protocols are usually relatively simple and relatively interesting. That is, it is possible for an outside reviewer to apply a reasonable level of effort to a security protocol or algorithm, learn something about it, and draw some useful conclusions. Furthermore, because of the broad potential impact of security algorithms and protocols, reviewers may be motivated by the prospect that effort applied will be rewarded by publication or by other forms of recognition.
3. Disclosure of source code The argument that disclosure of source code makes for better security would appear to follow naturally from the argument for disclosure of algorithms and protocols: if scrutiny of high level information is good, scrutiny of the source code that conveys ultimate detail must be better. And to a large extent, this argument is correct. To misquote Earl Boebert, “security is in the weeds” and the assurance of security ultimately rests on source code. A major issue with realizing the security benefits of source code access is getting anyone to read the source code. The author was closely associated for several years with a software product that was shipped to customers with source code, and whose core functions were made available in source code form for public scrutiny, use, and modification. Neither public reviewers nor paying customers reported security problems after the Beta stage. The product was a simple one that was remarkably free of security problems, and the marketing team made considerable hay out of the fact that it was a product that was shipped with source code. While there is no indication that source code review did any harm to the security of our product or our customers, there is not much reason to believe it did any good. Our
experience was that our customers were too busy using the product to review its source code. Some independent security consultants and enthusiasts did pay close attention to the free source code, especially during Beta, but in retrospect, few tangible benefits resulted from its availability. The “dark side” of access to source code is enhanced opportunity for malicious parties to develop attacks based on detailed knowledge of flaws. To date, most of the attacks reported on the “full disclosure” mailing lists have involved looking at APIs, hypothesizing flaws, and running tests. These methods have been used on both systems where source code is available and systems where it is not. Attacks based on source code have been the exception rather than the rule. However, where attacks based on source code have been developed – the Air Force Multics penetration is a historical example and the penetration of a PC Week web server test site a recent one – they have proven devastating. Access to source code can provide the leverage to build a subtle and sophisticated attack against a widely deployed system. The lesson from this experience is not that there is no benefit to security from access to source code. Rather it is that security review of source code is hard work, and that a product that seeks security benefits – as opposed to marketing benefits – by making its source code available must consider how it will make real security review happen. There are relatively few people who have the expertise to conduct a thorough security review of a large, functionally rich product. If their efforts can be brought to bear on a product in a managed way – whether on a for-hire or pro bono basis – the prospects for improving its security are good. However, simply posting source code to a global audience does not guarantee in-depth expert security review, and is unlikely to achieve the desired results. And disclosing the source code of a product may expose it to subtle and malicious attacks that greatly jeopardize its user base.
4. Open contribution to source code The final model of source code access involves not only open review of source code, but also an open community development process. The range of variation in goals and organization of such a development process can be extremely wide, from very disciplined to very casual. Others with more direct experience of such development will provide their perspective, but this paper will offer some observations from the perspective of secure product development in industry. A secure product development team consists of more than architects and developers. At Microsoft, our development groups include roughly one professional
0-7695-0665-8/00 $10.00 ã 2000 IEEE
tester for each developer. Product teams that have major security goals incorporate dedicated security test teams in addition to groups focused on architecture, design, and code review. The security test teams have a charter to range across the product seeking potential vulnerabilities and reporting them to the development groups. While design and development are the jobs that naturally carry visibility and recognition in a contributed source code environment, in a commercial team recognition and rewards are not confined to the developers. Security test teams have access to source code and the fact that they are employees means that they will read the code and be rewarded for effectively seeking out vulnerabilities. The heavy investment in security design review and testing causes many security vulnerabilities to be eliminated before the product is shipped to customers. A corporate environment can also ensure that a product is subject to challenges that even the most dedicated contributory effort cannot pose. A new version of the product is built each day and subjected to stress testing and active use by the entire development team. If a component requires ten or twenty computers to ensure effective stress testing or “wring out” a scenario, that configuration will be made available. Inevitably in a large commercial product, vulnerabilities remain. A commercial development team has an organized process for evaluating reported vulnerabilities, fixing those that are real, and testing the fixes to ensure that they do not “regress” another area of the product in the process of fixing the initial problem.
5. Source code access and security There is no question that source code review is a key component of building a secure system. However, simply making source code available for review does not guarantee that an effective security review will occur. Builders of secure systems must ensure that their security test and review teams have the resources and motivation to perform a thorough and effective test of the system. The “old fashioned” way to achieve this is to hire people or contract with organizations that will do the testing and review. The negative impact on security of source code access is as yet unmeasured. If systems have vulnerabilities and their source code is available for review, then those vulnerabilities are open to discovery and exploitation. But reading source code has only occasionally been the method of choice for breaking into systems, and while it may prove dangerous when used against widely deployed systems, the magnitude of this potential negative remains to be evaluated.
