Top FOSS security vulnerabilities

Palamida, the San Francisco company that helps companies to audit their use of open source software, has released a list of what it calls “the top five most overlooked open source vulnerabilities.” To this list, Palamida has added an additional five vulnerabilities exclusively for Linux.com.

The list is partly a promotion of Palamida’s Vulnerability Reporting Solution, which recently added 431 security alerts based on National Vulnerability Database listings. However, the list is also designed to draw attention to the lax practices surrounding the use of open source software in business, according to Theresa Bui, co-founder and vice president of marketing at Palamida.

To be precise, the vulnerabilities on the list are based on Palamida’s audits of its clients. These audits vary from scans of a few hundred megabytes of code to hundreds of gigabytes in a company’s complete software infrastructure. The list summarizes the results of scanning 3-5 million lines of code, representing a minimum of 30% of the software that Palamida scanned for clients, and, more often, at least 50%.

“We collect information on the most popularly used open source projects and versions,” Bui says. But, although Palamida’s database lists some 884,000 projects and versions, it is unlikely to be complete.

“If there’s a Venezuelan university student out there who has his own open source project, hosted by himself, we probably don’t know about him, because the adoption of his project isn’t very high,” Bui says. “But does that mean that one of your developers couldn’t find his way to his home page? Absolutely, they could. We try to make sure that we cover all of the major repositories and the commonly used open source projects, but certainly there’s always going to be the one-off projects by individuals that are under the radar. As a company, you always have to be aware of that.”

Still, Bui asserts that the list reflects how open source software is being used in business today. “Ten to one, you go into any company out there and do a scan on their code base, you’re going to find one of these open source projects in there.”

The top 10 vulnerabilities

Palamida provided Linux.com with a spreadsheet listing the software affected, what it does, the nature of the vulnerabilities, and the patches and updates that correct the problems. The applications affected include versions of Apache Geronimo and Apache Struts, JBoss Application Server, OpenSSH and Open SSL, and common libraries such as Libpng, LibTiff, and Zlib.

All these vulnerabilities have patches or later versions of the software, Bui stresses. The trouble is that many companies are not aware of the patches and updates — nor, much of the time, even that they are using the software. Increasingly, the vulnerabilities are not in a company’s infrastructure, or on users’ desktops, but in the code that the companies are shipping.

Reasons for the vulnerabilities

Bui is quick to point out that the blame for these vulnerabilities is not free and open source software projects in themselves. “Open source projects are great at monitoring themselves,” she says. “When they realize they need a patch, that patch can be literally up within hours. The responsibility lies with the user of open source to make sure that he is using it responsibly and in compliance with his company’s policies and the project’s license. So, to be honest, I don’t see what open source projects could do better.”

Melisa LaBancz-Bleasdale, Palamida’s senior communications manager, says, “We’re not trying to say that these projects are riddled with vulnerabilities. That’s not the point. These projects have moved on and released much stronger versions. But if you’re stuck seven versions ago, then you’re running around with a security vulnerability in your organization needlessly.”

The problem is that the easy accessibility of free software code via the Internet means that developers can “download it to their desktop, start coding around it, then check it into your source code management system — all of that without fiscal, security, or legal oversight.” And, if code is unknown, a company’s security team doesn’t know to monitor it for updates.

This problem is exacerbated by the tight production schedules of most development projects. “Engineering teams are under the gun to get product out the door,” Bui says. “So why would they build from scratch a shopping cart when there are thousands of shopping cart widgets available for you on the Web to download?”

Another problem, LaBancz-Bleasdale suggests, is the sheer volume of code to audit in a large company, particularly if the audit is done manually.

However, perhaps the largest problem is that many companies are simply unaware of the need to keep abreast of vulnerability reports — especially if they are used to dealing with proprietary software, whose business model often revolves around encouraging customers to upgrade.

“Big companies spend so much time tagging hardware assets,” Bui says, “but they don’t spend nearly enough time — or any, sometimes — having their software assets tagged. And it is much harder to sneak a giant computer into a company and plug it into the network than it is to download a third-party application and insert it into your source code management system, so that now it’s behind your firewall.”

For all these reasons, security alerts for free and open source software continue to be widely neglected. “The security team,” Bui says, “is only as good as what the engineering team tells them they have. It really is a significant realization for a company to start with just the top vulnerabilities.”