Researchers Track Spread of Security Flaws in Software Libraries

More than 200 software products rely on a flawed OpenSSL component, which exposed users to attack until vendors patched the software. But OpenSSl wasn't the only component with flaws, according to two researchers.


When security researchers publicly released details of the Heartbleed OpenSSL flaw in April, Websites and application vendors rushed to fix their software to eliminate the vulnerability.

In the end, some 200 products and Web services—ranging from top online services such as Netflix and Google to nearly a score of Oracle products and almost every version off Linux—were affected by the security bug.

The well-known incident highlights the trouble with security vulnerabilities in popular infrastructure software, frameworks and libraries, according to Kymberlee Price, director of ecosystem strategy at Synack, and Jake Kouns, chief information security officer for Risk Based Security.

The two security professionals will present their analysis of popular software components—including LibPNG, used by more than 130 popular software products, and FreeType, used in more than 30 applications—during the Black Hat Security Briefings August 2-7 in Las Vegas.

"The model we have been looking at initially has been more of a disease-spread model, where you have one infective agent, such as (a vulnerability in) OpenSSL, and you look at where that is spreading to," Price told eWEEK. "The question for companies is, how many vaccines will you need to take every year ... and what is the cadence of those patches?"

Companies should take stock of all the software libraries that they use to develop their products or internal software systems and track the applications that rely on those components. A vulnerability can be amplified if it affects a fundamental third-party library and thus impacts every product that utilizes that software. To prevent their applications from inadvertently being weakened by unknown flaws, developers should track their usage of third-party software and monitor the libraries for vulnerabilities.

"You need that evaluation prior to selecting a library," Kouns told eWEEK. "There is a big difference between a library that is well maintained—sure, it might have vulnerabilities, but the team, whether open or closed, is on top of it—versus a library that is end of life or is written by a 13-year-old."

While third-party software frameworks and libraries have become a major concern to security professionals, many developers are not yet aware of the problem. Only 37 percent of developers, architects and managers, actively monitor their software components for vulnerability disclosures, according to a survey of nearly 3,400 people conducted by software management firm Sonatype in April.

Even if they were aware of a vulnerability in a library which they depended on, about 60 percent would have trouble tracking down the affected software, because they do not maintain an inventory of open-source components, according to the firm's 2014 Open Source Development Survey.

To use third-party software securely, companies should both track the vulnerabilities in the libraries and frameworks that they use. They should also keep an inventory of the software components that they use in their production applications, said Kouns of Risk Based Security.

"We continue to advise people that you want to work with vendors—whether closed or open or libraries or not—that get fixes out quickly," he said. "If you care about security, you want to use those products."

Robert Lemos

Robert Lemos

Robert Lemos is an award-winning freelance journalist who has covered information security, cybercrime and technology's impact on society for almost two decades. A former research engineer, he's...