Open source developers clueless about security disclosure, Rapid7 finds
- — 31 October, 2013 19:40
Open source developers can be just as clueless at handling third-party security disclosures affecting their products as the often-criticised closed source sector, a researcher for security firm Rapid7 has discovered after spotting exploitable issues in a clutch of popular web apps hosted on SourceForge.
Ironically, the easiest part of engineer Brandon Perry's security research appears to have been finding vulnerabilities in seven applications with a lifetime download count of 16 million. These ranged from an educational tool called Moodle (4.7 million downloads), a CRM tool called vTiger (3.6 million downloads) to relative minnows such as the OpenMediaVault (703,000) and NAS4Free home storage software.
Most of the issues related to problems in the design of applications (i.e. intended functions misused) while one - that found in Openbravo ERP - was a conventional software flaw.
Perry and Rapid7 admit two points about these applications; none is in the league of an Apache or a Wordpress and many of the installs might not in use any longer. But if even a few percent remain live that would still equivalent to hundreds of thousands of vulnerable targets.
Conventionally, some of the flaws might also be described as 'hacks' rather than flaws but to the pen-tester that makes no odds; if an attacker can misuse a function whose limitations are not adequately documented then it is a hole that gives attackers a way in.
Only three of the seven were patched during Rapid7's disclosure period.
The story should end with the news that Rapid7 has released modules that hit each issue for Metasploit, but the more interesting issue turned out to be the difficulties Perry's Rapid7 colleague Tod Beardsley (who handled disclosure) had in simply communicating with the projects themselves prior to going public.
"Despite this level of apparent popularity, though, the actual business of disclosing vulnerabilities to the software developers directly was... circuitous. Across these seven projects, I found there were at least seven different approaches to handling incoming vulnerability reports," said Beardsley in his blog.
Incredibly, during the disclosure period one of the projects had asked for a password-protected zip file containing the details while another "filed the issue on a public bug tracker which promptly e-mailed it back in cleartext," said Beardsley.
It was as if none of these FOSS (free and open source software) developers had even thought about having a structured disclosure policy because the applications had been built on their features alone. Security was for security applications.
"In the security space the awareness is much higher. If it's in another space their focus is different," Rapid7's product marketing manager Christian Kirsch told Techworld at this week's RSA Show in Amsterdam.
"There was a lot of education that we had to do along the way. They didn't seem to have a high level of security awareness," he said.
The team's advice to FOSS developers was to start by having a signed PGP key that authenticated the contact email address for third parties to communicate flaws. From that point onwards, all communications should use encryption and acknowledge receipt. Developers should make this whole process as easy to find and understand as possible.
Vulnerabilities that involved feature exploitation should be documented and communicated to the end users, many or all of whom will not be plugged into the CERTs and Bugtraqs used by developers.
Last but not least, the users of SourceForge should not blindly assume that open source applications are any more secure or any easier to secure when flaws are found. As with proprietary developers there seems to be good and bad, complacent and attentive.
Rapid7 details its disclosure policy on its website.