'Clonewise' Security Service Helps Identify Vulnerable Code

Open-source libraries and components have sped the development of software projects and lowered cost for developers, but many programmers continue to statically build copies of libraries into their code, creating a security nightmare.    

At the Black Hat USA security conference later this month in Las Vegas, doctoral student Silvio Cesare of Deakin University in Melbourne, Australia, will demonstrate a service for finding common code in programs -- a process that can help find vulnerable libraries built into larger bodies of code. Called Clonewise, the service currently focuses on finding patterns of source code -- anything from a full library to smaller snippets -- in the Ubuntu Linux distribution. The method can be used to find cloned code in any source file.

The problem of clones -- and vulnerabilities in statically linked code -- impacts a variety of software because so many programs incorporate open-source code.

"It is a real problem that needs to be addressed," Cesare says. "Every time there is a vulnerability in [the graphics libraries] libpng or libtiff, we are looking at a lot of major programs that could potentially be vulnerable."

In his own research, Cesare found that about one out of every 18 packages included in Ubuntu Linux has some code from another library. In total, some 400 libraries or embedded packages exist that could be built into any of the more than 10,000 packages in a common Linux distribution.

[Efforts to cull vulnerabilities generally target a company's own products, but in many cases, the risk is not in code that internal developers have written, but in components provided by outside developers. See Managing The Risk Of Flaws In Third-Party Software.]

It is not all about Linux, however. In the past, vulnerabilities in zlib have affected a large number of programs on many different platforms, including Windows. Flaws in the HTML rendering library Webkit have impacted browsers such as Apple's Safari or Google's Chrome, but also other applications, such as Entourage 2008 and Yahoo! Messenger.

"Static libraries and other reusable code chunks should definitely be a concern for application developers but the risk is often ignored because until the last few years it was difficult to tackle the problem cost effectively," says Chris Wysopal, chief technology officer for application-security firm Veracode. "Developers often don't think it is there problem because they didn't write the code, they just reused it."

Inside companies, many software developers frequently use open-source libraries as a matter of course and build the libraries into their programs. With homegrown applications built using enterprise languages such as Java and .NET, there is no standard way to monitor and maintain the third-party code that frequently finds its way into the programs, says Eric Sheridan, chief scientist for static analysis at WhiteHat Security, a Web security provider.

A developer building an application today in Java would go out and use Google to search for code libraries and build them into their project, he says.

"At the time that you google them, you have the latest versions of those libraries, but from that moment forward, it becomes stale," Sheridan says. "The moment they download those libraries, they leave it 'as is' -- an application built a year ago has all the vulnerabilities found since then."

Most projects follow the 80-20 rules, says Jeff Williams, CEO of security consultancy Aspect Security. Every month, Aspect looks at some 5 million lines of custom code, but that generally only accounts for 20 percent of the code incorporated into a program. The rest is in the form of open-source components that are built in, he says.

Williams worries about more than just older, vulnerable code. Where Clonewise focuses on trusted libraries that have become outdated, enterprise developers also need to worry about malicious code inserted into a library -- a much harder problem to detect, he says.

"Companies are getting good results, and they are building better software, but they are taking risks and the danger is that they don't understand those risks," he says.

Software developers who use open-source code in their projects need to establish a process to track and manage vulnerabilities in third-party components. For the most part, they should stick to dynamically linked libraries and use the packages included in their distributions, says Deakin University's Cesare.

"They should be aware of what is in their source ... and not bundle every component into their code," he says. "If there is a significant need, and they need to put in their code, then they need to be very vigilant."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.