Impact assessment for vulnerabilities in open-source software libraries Henrik Plate, Serena Elisa Ponta, Antonino Sabetta, SAP Labs France 10 April 2015 oftware applications integrate more and 1 Introduction more open-source software (OSS) to Sbenefit from code reuse. As a drawback, The adoption of open-source software (OSS) in the each vulnerability discovered in bundled OSS software industry has continued to grow over the past potentially affects the application. Upon the few years and many of today's commercial products disclosure of every new vulnerability, the ap- are shipped with a number of OSS libraries. Vulnera- plication vendor has to decide whether it is bilities of any of these OSS libraries can have consid- exploitable in his particular usage context, erable consequences on the security of the commercial hence, whether users require an urgent ap- product that bundles them. The relevance of this plication patch containing a non-vulnerable problem has been acknowledged by OWASP which version of the OSS. Current decision making included \A9-Using Components with Known Vulner- is mostly based on high-level vulnerability de- abilities" among the Top-10 security vulnerabilities scriptions and expert knowledge, thus, effort in 2013 [1]. The disclosure in 2014 of vulnerabili- 1 2 intense and error prone. This paper proposes ties such as Heartbleed and ShellShock contributed even further to raise the awareness of the problem. arXiv:1504.04971v2 [cs.CR] 21 Apr 2015 a pragmatic approach to facilitate the impact assessment, describes a proof-of-concept for Despite the deceiving simplicity of the existing Java, and examines one example vulnerabil- solutions (the most obvious being: update to a more ity as case study. The approach is indepen- recent, patched version), OSS libraries with known dent from specific kinds of vulnerabilities or vulnerabilities are found to be used for some time af- programming languages and can deliver im- ter a fixed version has been issued [2]. Updating to a mediate results. more recent, non-vulnerable version of a library repre- sents a straightforward solution at development time. However, the problem can be considerably more diffi- cult to handle when a vulnerable OSS library is part 1http://heartbleed.com/ 2https://shellshocker.net/ Page 1 of 11 of a system that has already been deployed and made Section 7 concludes the paper. available to its users. In the case of large enterprise systems that serve business-critical functions, any change (including updates) may cause system down- 2 Approach time and comes with the risk that new unforeseen issues arise. For this reason, software vendors need Concept to carefully assess whether an application requires an In order to assess whether or not a given vulnerability urgent application patch to update an OSS library, in an OSS library is relevant for a particular applica- or whether the update can be done as part of the tion, we consider the corresponding security patch, application's regular release cycle. i.e., the set of changes performed in the source code The key question that vendors have to answer is of the library in response to the vulnerability. Our whether or not a given vulnerability, that was found approach is than based on the following pragmatic in an OSS library used in one of their products, is assumption: indeed exploitable given the particular use that such a product makes of that library [3]. If the answer(A1) Whenever an application that includes a library is positive, an application patch must be produced, (known to be vulnerable) executes a fragment of and its installation needs to be triggered for all exist- the library that would be updated in a security ing deployments of the application. If the answer is patch, there exists a significant risk that the negative, the library update can be scheduled as part vulnerability can be exploited. of the regular release cycle, without causing extra efforts related to urgent patch production by vendors The underlying idea is that if programming con- 3 and patch installation by users. The current practice structs that would be changed by the patch are of assessing the potential impact of a vulnerability in used, than the application is using code involved in OSS is time-consuming and error-prone. Vulnerabili- the vulnerable part of the library. Therefore, we ties are typically documented with short, high-level collect execution traces of applications, and compare textual descriptions expressed in natural language; at those with changes that would be introduced by the the same time, the assessment demands considerable security patches of known vulnerabilities in order to expert knowledge about the application-specific use detect whether \critical" library code is executed. of the library in question. Consequences of wrong as- Figure 1 illustrates the approach graphically: The sessments can be expensive: if the developer wrongly change-list Cij represents the set of all programming assesses that a given vulnerability is not exploitable, constructs of OSS component i that were modified, application users remain exposed to attackers. If added or deleted as part of the security patch for she wrongly judges that it is exploitable, the effort vulnerability j. Change-lists can be computed as of developing, testing, shipping, and deploying the soon as a security patch has been produced for a patch to the customers' systems is spent in vain. vulnerability. Patches can be assumed available at This paper presents a pragmatic approach that the time vulnerabilities become public in the case of contributes to simplify the decision making. We do responsible disclosure. The trace-list Ta represents so by automatically producing (whenever possible) the set of all programming constructs, either part concrete evidences supporting the case for urgent of application a or any of its bundled libraries, that patching. More specifically we assess whether an were executed at least once during the runtime of application uses (portion of) a library for which a application a. The collection of traces can be done at security fix has been issued in response to a vulner- many different times, starting from unit tests until ability. The approach seamlessy integrates in the the application is deployed for productive use. usual development workflow without requiring addi- The intersection Cij \ Ta comprises all those pro- tional effort from developers and is independent of gramming constructs that are both subject to secu- programming languages and vulnerability types. rity patch j and have been executed in the context The paper is organized as follows. Section 2 of application a. Following assumption (A1), a non- presents our approach and a generic architecture empty intersection Cij \Ta indicates that a newly dis- that supports it. Section 3 describes our prototypi- closed vulnerability is highly relevant, due to the risk cal implemention and its application to a case study. of exploitability. An empty intersection, on the other Section 4 outlines observations regarding the inte- 3We use the language-agnostic term \programming construct" gration and quality of information stemming from to refer to structural elements such as methods, construc- different sources. Section 5 presents related literature. tors, functions and so on. Page 2 of 11 hand, may result from insufficient coverage, hence, it It also presents assessment results concerning the does not automatically render a vulnerability irrele- relevance of vulnerabilities to the security expert of vant. Coverage is described by the intersection of the the respective application. sets Ta \ Sa, where Sa is the set of all programming The Patch Analyzer is triggered upon the publica- constructs belonging to the application itself. The tion of a new vulnerability for an open-source library. larger the intersection, the better the coverage, and It interacts with the respective Versioning Control the greater the confidence that constructs belonging System (VCS), identifies all programming constructs to Cij cannot be reached. changed to fix the vulnerability, and uploads their Library versions can be disregarded, provided that signatures to the central Assessment Engine. This the traces were collected before the release of a se- change-list is built by comparing the vulnerable and curity patch and that all existing library versions patched revision of all relevant source code files of the are affected by the vulnerability. In other cases (in library. The corresponding commit revisions can be particular if traces are more recent than a patch, and obtained from the vulnerability database, searched if the corresponding constructs exist in both vulner- in the commit log, or specified manually. able and patched library version) one has to identify The Runtime Tracer collects execution traces of and compare the version of the library producing the programming constructs, and uploads them to the trace with the ones affected by the vulnerability. central engine. This is achieved by injecting instru- Our approach is not immune to reporting false- mentation code into all programming constructs of positives and false-negatives. False-positives occur the application itself and all the bundled libraries. if a vulnerability is not exploitable despite a non- The instrumentation can be done dynamically, dur- empty intersection Cij \ Ta, which is due to the fact ing the actual runtime, or statically, prior to the that exploitability can depend on many other con- application's deployment. The former can guarantee ditions, e.g., the presence of sanitization techniques the tracing of all programming constructs used at in the application or specific configuration settings. runtime including, e.g., libraries included at runtime False-negatives occur if vulnerabilities are exploitable and parts of the runtime environment. Its major despite an empty intersection Cij \ Ta, which can drawback is the impact on application startup, in result from insufficient coverage, a problem shared particular if many contructs need to be loaded be- with many techniques relying on dynamic execution fore the applicaton becomes available to its users, as (as opposed to static analysis).