BACKGROUND
Over the last few years, third-party code has moved from a minor factor in software development to a dominant force in the industry. It is now used throughout software development in all applications, from highly sensitive government and military applications to security-intensive consumer commerce and communications.
According to the latest report from VDC Research, the majority of software that runs on embedded devices is now developed by external sources, not in-house development teams. Some of this is open source, but in embedded applications, nearly 30% of code is third-party commercial software – so the source is often unavailable. Such components include graphics and windowing toolkits, cryptography libraries, middleware, databases, and others.
As a result of this outsourcing, the behaviors of significant parts of applications are actually hidden from most of today’s popular code analysis tools. Because third-party software is commonly delivered only in executable form, it cannot be examined with commercially available static source code analysis tools. Without access to the source code, these tools cannot fully account for the security consequences of executing the third-party code in the application.
Based on over 10 years of research, through collaboration with the University of Wisconsin and with support from the United States Navy, Air Force Research Labs (AFRL), and Defense Advanced Research Projects Agency (DARPA), GrammaTech has developed an advanced new capability that uses binary analysis to examine third-party code without requiring access to source code.
GrammaTech has integrated this binary analysis capability into their proven static analysis tool, CodeSonar, to create the first commercially-available binary analysis product. CodeSonar’s binary analysis technology provides developers with the ability to evaluate, test, and inspect third-party code, all while reaping the benefits of advanced workflow options and management tools.
THE DANGERS OF THIRD-PARTY CODE
Development teams commonly turn to third-party software to incorporate particular functionality, such as communications or graphics, into their applications.
Cost, lack of local expertise, and unwillingness to “reinvent the wheel” are among the many sound reasons that organizations use third-party software, whether as components in their own products or as tools to support organizational activities. By outsourcing this development task, teams can focus more on the core functional capabilities of their software and dramatically accelerate time-to-market for their products.
Unfortunately, developers and the organizations they work for often fail to consider the following: When an organization releases software that includes third-party code, it becomes responsible for every line of code inside the application – including all of the third-party code.
An attacked organization can suffer significant losses. Producers who ship vulnerable code that is subsequently attacked can expect to lose reputation along with time and money. And even if vulnerabilities are not used as a basis for attack, they can cause difficulties when the software is used normally, which can entail costly remediation.
Changes in development practices, ever-widening supply chains, and the rapid growth of code bases means it is now, more than ever, a dangerous assumption to hope that third-party code vendors have maintained and documented best-practice security checkpoints during the development process. It is increasingly clear that trust in a producer is by no means sufficient to guarantee an acceptable level of risk.
Malicious entities can distribute counterfeit products, for example, to exploit the reputations of trusted producers. And genuine products themselves are not guaranteed to be risk-free: they can be tampered with in transit or sabotaged by malicious insiders within a trusted organization. Even if a genuine product is created by entirely trustworthy staff and delivered through a secure channel, vulnerabilities may still flow through from further up the supply chain.
It is worth noting, also, that exploitable software vulnerabilities are not always caused by malicious interference. Errors that introduce zero-day exploitable buffer overruns, for instance, can arise from outdated design documents, misunderstandings about arcane language details, even typographical errors.
So what can development teams do to ensure greater safety in products that use third-party code?
BINARY ANALYSIS: AN INNOVATION TO ENSURE THIRD-PARTY CODE SAFETY
Instead of attempting to formulate and enforce security requirements over the entire upstream portion of the supply chain, organizations can now employ a more practical approach. By leveraging binary analysis, organizations can focus on establishing trust in incoming software at the point of use, and in outgoing software at the point of dispatch.
This approach also permits organizations to consider a much broader range of software: products from new companies without established reputations, software obtained over unsecured networks, and even components whose provenance is completely unknown.
When you are able to analyze binaries, you can scan software components, such as libraries or full appli cations, without requiring their source code. CodeSonar can even analyze executables that have been “stripped” of symbol table and debugging information.
Binary executables can either include the symbol-table/debugging information (“unstripped”) or not (“stripped”). Software producers may strip their binaries for a range of reasons, from benign (saving space), to proprietary (protecting trade secrets against reverse engineering), to hostile (obfuscating the code to hide a virus).
In order to find bugs, security vulnerabilities, or malicious code (backdoors, time bombs, or logic bombs) in an application delivered as stripped machine code, developers must be able to analyze stripped executables.
Static analysis of stripped executables is beyond the capabilities of most static analysis products. CodeSonar, on the other hand, can perform static analysis on both stripped and unstripped executables.
Through this evolution in static code analysis, developers can inspect and evaluate all externally-produced code used in their applications. Binary analysis results can also be used to compare and contrast the relative safety of different third-party components, so teams can make the best possible decision when choosing components to include in their applications.
INTEGRATED ANALYSES
Often, the software resources available for analysis include a combination of machine code and source code. For software developed entirely in-house, full source code is usually available for analysis alongside the finished program binaries.
When third-party components are being evaluated, on the other hand, they are often only available in binary form, but source is typically available for large parts of the system into which they will be integrated. In this way, organizations attempting to integrate systems will generally be working with both machine code and source code at any given time.
CodeSonar can analyze such code, using the additional information provided, to strengthen the analysis and improve the quality of feedback wherever possible.
An additional advantage of analyzing binary code is that it represents exactly the software that will be executed by the hardware. Source code, by contrast, does not provide the whole story: the influence of the compiler must also be taken into account. Source code language definitions are full of ambiguities and inconsistencies. In such cases, the compiler is free to resolve these as it generates the machine code. Compiler optimizers frequently take advantage of these ambiguities. Thus, the semantics of the source code may even be different depending on the level of optimization used. Additionally, the compiler itself may contain flaws and generate incorrect code.
The example above shows a compiler-introduced error found during a 2002 security review at Microsoft. The compiler concluded that the memory was never accessed post-memset( ), and so the memset( ) call could be removed, meaning that the cleartext password remained on the stack.
When analyzing binary executables, on the other hand, all of these compiler effects have already manifested, so the analysis has much higher fidelity.
Analyzing binaries with automated static analysis – in which run-time properties of programs are computed without actually executing the programs – has some important advantages over other methods for security assessment.
Unlike manual inspection, it scales readily to the size and complexity of modern software. Unlike testing, which can only ever cover a tiny portion of the possible execution cases, static analysis approaches coverage of all possible executions. Unlike dynamic analysis, which examines software as it runs, static analysis does not involve executing software. Inspection, testing, and dynamic analysis can be helpful adjuncts to static analysis, but they cannot replace it.
The following diagram demonstrates how binary analysis expands the code analysis footprint of an application.
BEST PRACTICES FOR SECURING THIRD-PARTY CODE
Used early in the development lifecycle, an automated binary analysis tool will help development teams select the safest components to include in their completed applications. Additionally, when using third-party code to build an application, development teams should follow other third-party code best practices, as described below.
Legal requirements: When contracting with a third-party software vendor, specify in the contract itself the security limitations your development team is willing to accept, as well as what constitutes a transference of liability to the third-party vendor.
Reporting transparency: Require that third-party vendors, in lieu of sharing their source code, share reports from their own use of automated software analysis tools and manual testing evaluations.
Coding standards: Discuss compliance of coding standards with third-party software vendors to understand what inconsistencies in their code may generate potential exploits, and to gain better knowledge of your vendor’s coding process.
Communication: After analyzing your final application with binary analysis, work with your third-party vendors to improve the overall security of their code, and, by extension, your application as well.
CONCLUSION
Due to the continual proliferation of malicious attackers and the growing sophistication of cyber-warfare between nations, exploiting vulnerabilities in third-party code is an expanding frontier. Software developers must actively defend their applications against this threat to avoid application failure.
Leveraging binary analysis to test and inspect the executables of third-party code will help developers build safer applications and instill greater confidence in the companies or government agencies that rely on the security of their software.
CodeSonar’s binary analysis capability empowers developers with a new depth of understanding about how secure applications truly are. Although acceptance testing of third-party components such as libraries remains important, developers are now able to build even safer applications by analyzing these components in the context in which they are being used.
Further, extending security efforts into third-party code has important business benefits. It can accelerate development cycles, improve the security of software, and ultimately increase customer satisfaction.
Adding binary analysis to the development process allows developers to test a more holistic representation of their final application, which helps organizations deliver more trusted applications to customers and eliminate potential liabilities due to vulnerable third-party code.
References:
The Global Market for Automated Test and Verification Tools, VDC Research, 2013
WYSINWYX: What You See Is Not What You eXecute, IFIP Working Conference on Verified Software: Theories, Tools, Experiments (VSTTE), Balakrishnan, G., Reps, T., Melski, D., and Teitelbaum, T., 2005. Zurich, Switzerland: Springer.
Investigative Report on the U.S. National Security Issues Posed by Chinese Telecommunications Companies Huawei and ZTE, House Permanent Select Committee on Intelligence 112th Congress 2nd Sess., . 2012, USGPO.