The OpenNMS Group recently learned about and fixed a security vulnerability that allowed remote code execution. CVE-2020-12760 applies to OpenNMS Horizon before 26.0.1, and Meridian before 2018.1.19 and 2019 before 2019.1.7. We advise customers to review the CVE and upgrade to the latest versions.

No one wants to have a security vulnerability, particularly with network management software, where the consequences could be serious. Through careful development, robust testing, and community and corporate vigilance, The OpenNMS Group does its best to produce secure software our users can trust. When someone notifies us about a security issue, we take action quickly to determine the severity, address it, and notify users.

1. Discovery

There are several ways we might learn about a security issue: from a community user, from a customer who finds something during their own routine internal IT security scanning processes, or through security researchers who actively look for security vulnerabilities in software and hardware. Contacting us through [email protected] sends a message to our security team, made up of key people from our development, customer support, and executive teams.

2. Responsible Disclosure

When we receive a notification about a possible security vulnerability, we immediately reach out to the reporter, using secure messaging, including PGP when working with researchers, if they wish. We thank them for notifying us, and particularly for choosing to disclose this information responsibly.

Dealing with a security vulnerability is a race to address it before it becomes widely known and exploitable. It requires balancing the ability to fix the vulnerability before someone exploits it and the risk to customers until that vulnerability is fixed.

For this reason, we appreciate responsible disclosure, which basically means the person who discovered the vulnerability does not publicize it until we have a chance to deal with it. In return, we take action immediately, and are transparent with the person who reported the issue, to keep them aware of our progress. In the case of CVE-2020-12760, we thank Florian Hauser, who works for Code White, for notifying us of this issue.

3. Verify Proof of Concept

Reporters usually provide us with a proof of concept (PoC) of how to exploit the problem they found and the steps to reproduce it. As mentioned earlier, CVE-2020-12760 allowed remote code execution.

The engineering team validates the PoC code, to determine the nature of the vulnerability and if it is reproducible. In some cases, the reporter may have been using an old version of the software, in which case we may have seen the issue already and fixed it, and it does not impact new versions of the software. We thank the reporter, and keep a bug report of the issue. Researchers usually work against the latest version, but sometimes they might use the most widely deployed version. Regardless, we take these reports seriously and investigate them.

4. Triage and Work

Once we verify the PoC, we determine the severity of the vulnerability, and create a JIRA issue visible only to core OpenNMS contributors. This keeps the issue hidden from searches until the bug is fixed to minimize the chance of someone exploiting the vulnerability. Once fixed, we change the permissions on the JIRA issue so that it becomes public and people can see a record of how it was fixed.

In serious and wide-spread cases, we inform Support and Meridian customers who might be exposed about the vulnerability, that we are addressing it, and to be prepared to install a fix when it becomes available. In some cases, there is a temporary workaround that we tell them to deploy until a fix is ready.

We update the reporter regularly on our progress with the issue, including PDF exports of the JIRA issue history. If they have an ID on our system, we add them to the permissions so they can follow the JIRA ticket.

5. Fix and Testing

All our work is done in GitHub. When we have a fix, we test it by running the PoC attack and verifying that the issue has been addressed, iterating as necessary until we have fixed the vulnerability. The researcher has the opportunity to test the fix, and once validated, we issue a new release and announcement about the vulnerability and fix.

6. Declaration and Communicating the Fix

When the fix is ready, we roll it out as soon as possible, with the next software release, or in an off-schedule release. We include information about the vulnerability in the release notes, social media, and blog posts, as well as notifying customers who are exposed. We make the JIRA issue public, and we credit the person who discovered the issue in these communications, unless they request not to be identified.

With severe issues we may create a CVE (Common Vulnerabilities and Exposures) declaration, that appears on a publicly maintained database of known exploitable vulnerabilities. This allows people to search for and discover OpenNMS security vulnerabilities and act accordingly to secure their system if they are affected. We also inform the reporter about the CVE.

We’re Never Done with Security

The world is full of “bad guys” ready to take advantage of people and their weaknesses, and of course, the Internet is no different. We must always be vigilant to potential threats, and think like the bad guys to stay ahead of them.

Building robust security testing processes into development, and using the latest tools and technologies (like OWASP, GitHub’s Dependabot, and SonarCloud, for example) to identify dependencies and fix vulnerabilities before release, are just some of the ways we can do this. Responsible disclosure and the efforts of security researchers, customers, and the OpenNMS community, are an essential part of the effort to help keep our products—and your business—secure.