Dr. Binary: searching statically linked vulnerable functions in minutes

1. Introduction

 A complex software product often contains packages, libraries, or modules made by third parties, and these third-party components may again contain components from other sources. This is known as the software supply chain. Software supply chains are increasingly complicated, and it can be hard to detect statically-linked copies of vulnerable third-party libraries in executables. 

This blog post discusses how to use Dr. Binary to search statically linked vulnerable functions in executables.  We built httpd with statically linked OpenSSL library 1.0.2a. This OpenSSL has many known vulnerabilities (e.g., CVE-2015-1788). They are statically linked so such vulnerability cannot be detected simply by version based detection approaches. The following paragraphs will illustrate how to use Dr. Binary to identify this statically linked vulnerable function. 

Dr.Binary: Searching Vulnerabilities in Binaries

A vulnerability scanner is at the heart of a typical vulnerability management solution. It uses a list of known vulnerabilities to spot potential problems of the system.  Traditionally, a vulnerability scanner either conducts dynamic penetration test or statically checking the version of examined software for a match in a vulnerability database.  The more information the scanner has, the more accurate its performance.

Instead of conducting a penetration test or checking the version of binaries to find the known vulnerabilities, Dr. Binary took a different approach:   A software vulnerability can be represented as one or several code fragments.  Dr. Binary first extracts the vulnerable code fragments and generate "embeddings" as the vulnerability signature. Then given an input program, Dr. Binary decomposes it into code fragments, generate their embeddings, and then check these embeddings with the ones in the vulnerability database, to determine the presence of vulnerability.