Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


'Clonewise' Security Service Helps Identify Vulnerable Code

Researcher at Black Hat to demonstrate service that can help find vulnerable libraries built into larger bodies of 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.

Click here for more of Dark Reading's Black Hat articles.

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.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Our Endpoint Protection system is a little outdated... 
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2019-12-12
The express install, which is the suggested way to install Puppet Enterprise, gives the user a URL at the end of the install to set the admin password. If they do not use that URL, there is an overlooked default password for the admin user. This was resolved in Puppet Enterprise 2019.0.3 and 2018.1....
PUBLISHED: 2019-12-12
When using the cd4pe::root_configuration task to configure a Continuous Delivery for PE installation, the root user�s username and password were exposed in the job�s Job Details pane in the PE console. These issues have been resolved in version 1.2.1 of the ...
PUBLISHED: 2019-12-12
An exploitable code execution vulnerability exists in the DICOM packet-parsing functionality of LEADTOOLS libltdic.so, version 20.0.2019.3.15. A specially crafted packet can cause an integer overflow, resulting in heap corruption. An attacker can send a packet to trigger this vulnerability.
PUBLISHED: 2019-12-12
An exploitable information disclosure vulnerability exists in the DICOM packet-parsing functionality of LEADTOOLS libltdic.so, version 20.0.2019.3.15. A specially crafted packet can cause an out-of-bounds read, resulting in information disclosure. An attacker can send a packet to trigger this vulner...
PUBLISHED: 2019-12-12
An exploitable denial-of-service vulnerability exists in the Dicom-packet parsing functionality of LEADTOOLS libltdic.so version 20.0.2019.3.15. A specially crafted packet can cause an infinite loop, resulting in a denial of service. An attacker can send a packet to trigger this vulnerability.