See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/3851987
`
`Security and source code access: Issues and realities
`
`Conference Paper · February 2000
`
`DOI: 10.1109/SECPRI.2000.848476 · Source: IEEE Xplore
`
`CITATIONS
`9
`
`1 author:
`
`Steve Lipner
`SAFECode
`
`33 PUBLICATIONS   969 CITATIONS   
`
`SEE PROFILE
`
`READS
`35
`
`All content following this page was uploaded by Steve Lipner on 17 October 2014.
`
`The user has requested enhancement of the downloaded file.
`
`DivX, LLC Exhibit 2019
`Page 2019 - 1
`Netflix Inc. et al. v. DivX, LLC, IPR2020-00614
`
`

`

`Security and Source Code Access: Issues and Realities
`
`Steven B. Lipner
`Microsoft Corporation
`SLipner@microsoft.com
`
`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
`
`in cryptography, where
`roots
`its
`Bad Thing has
`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
`
`0-7695-0665-8/00 $10.00 2000 IEEE
`
`DivX, LLC Exhibit 2019
`Page 2019 - 2
`Netflix Inc. et al. v. DivX, LLC, IPR2020-00614
`
`

`

`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
`
`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.
`that
`While design and development are the jobs
`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.
`
`0-7695-0665-8/00 $10.00 2000 IEEE
`
`
`
`View publication statsView publication stats
`
`DivX, LLC Exhibit 2019
`Page 2019 - 3
`Netflix Inc. et al. v. DivX, LLC, IPR2020-00614
`
`