While major open source projects like Apache and Mozilla have clear procedures for handling vulnerability disclosures, many projects need to improve the way they deal with such issues, according to researchers at security firm Rapid7.

Researchers: Open source projects need better vulnerability handling policies

on Nov 5, 13 • by Chris Bubinas • with 2 Comments

While major open source projects like Apache and Mozilla have clear procedures for handling vulnerability disclosures, many projects need to improve the way they deal with such issues, according to researchers at security firm Rapid...

Home » Software Security » Researchers: Open source projects need better vulnerability handling policies

While major open source projects like Apache and Mozilla have clear procedures for handling vulnerability disclosures, many projects need to improve the way they deal with such issues, according to researchers at security firm Rapid7. Reporting that it had found vulnerabilities in seven popular open source applications and added them to its popular Metasploit penetration testing tool, the firm offered some guidelines intended to help strengthen the security of open source projects.

Many open source advocates suggest that such software is more secure than normal commercial programs due to the number of people looking at and revising the code. However, the rate of defects in such code is generally about the same, White Source CEO Rami Sass noted in a recent post on Opensource.com. Underscoring that point, Metasploit contributor Brandon Perry recently went on SourceForge and began probing seven of the most popular open source tools available for vulnerabilities.

Within two weeks, according to Network World, he had found possible exploits in Moodle, vTiger CRM, Zabbix, Openbravo ERP, ISPConfig, OpenMediaVault and NAS4Free, all of which have since been added to Metasploit. Six are remote command execution flaws, while the seventh, in OpenBravo ERP, is an XXE arbitrary file read flaw. Perry and Rapid7 reported the flaws to the developers and worked with the Computer Emergency Response Team Coordination Center to handle the disclosures. OpenBravo ERP and vTiger CRM have since patched the flaws. NAS4Free has not responded to the disclosure, while the other four applications have refused to issue fixes, as they believe the remote command execution features are by design.

Improving vulnerability handling
In total, the applications have logged 16 million downloads in their lifetime, which means that even if only one to two percent of those are active installs, as many as a quarter million devices could be exposed, Rapid7’s Tod Beardsley noted in a blog post. Yet while the vulnerabilities are notable, the more telling issue from the findings may be that these open source projects do not have clearly defined procedures for handling vulnerabilities.

“Despite this level of apparent popularity, though, the actual business of disclosing vulnerabilities to the software developers directly was … circuitous,” Beardsley wrote. “Across these seven projects, I found there were at least seven different approaches to handling incoming vulnerability reports.”

Compared to the process on a project like Mozilla, which offers bug bounties, many smaller projects seem to lack any kind of standardized process or preparation at all, he explained. Rapid7 proposed a checklist for smaller projects to follow. Among the suggestions offered were to have a designated email address that relies on encrypted communication, to make sure to acknowledge the receipt of disclosures and to have a contract with CERT/CC.

The process should then involve issuing a patch and a disclosure notice, Beardsley added. One important thing to remember in open source projects is that “not every vulnerability is a bug in code.” A patch might simply be a change in the documentation for the project to acknowledge the potential for an exploit.

Such precautions could certainly go a long way toward improving the software security of open source code, which has become a much-discussed concern lately. Recently, Google announced that it would be offering bug bounties for vulnerability disclosures on several open source projects – with more projects likely to follow – which could be a helpful step in standardizing disclosure processes. Small projects often face the challenge of limited resources to handle bugs, and additional efforts by outsiders or contributors can go a long way. Developers can work to reduce bugs across open source projects and libraries by using tools like static analysis software, for instance. By catching their own errors before submitting additions, programmers can build stronger projects from the outset and reduce confusion down the line.

Software news brought to you by Klocwork Inc., dedicated to helping software developers create better code with every keystroke.

Related Posts

2 Responses to Researchers: Open source projects need better vulnerability handling policies

  1. Chris Bubinas says:

    It’s so true Jessica, and with so many important and successful open source initiatives it really becomes a problem. The bad guys are always looking for software that is common enough to be worth exploiting, when you think of the adoption rates for something as simple (and awesome) as VLC Media Player (http://www.videolan.org/) alone, it really puts the risk into perspective.

    Thanks for sharing your thoughts and have a great weekend!

    Chris

  2. “many smaller projects seem to lack any kind of standardized process or preparation at all”
    That makes sense. When a lot of hands are involved each developer is going to have their own process and set of steps they usually take. But those processes don’t necessarily overlap and that can leave security breaches that no one is aware of. Smaller projects might also have fewer eyeballs looking at them, and that means someone might find a gap the original developer wasn’t thinking about looking for.

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top