Top 5 New Open Source Security Vulnerabilities in March 2019

April 4, 2019 Patricia Johnson

We all sprang forward with daylight savings this past March, losing an hour of sleep and hopefully giving spring a much-needed nudge. However, even daylight saving didn’t keep our hardworking knowledge team from burning the midnight oil and reviewing all of the recent open source security vulnerabilities in our database to bring our faithful readers the lowdown on March’s top 5 new open source vulnerabilities.

The WhiteSource database continuously collects known open source security vulnerabilities from a number of well-respected community resources like the National Vulnerability Database (NVD), and other public, peer-reviewed security advisories, and issue trackers.

So, without further ado, here are the top 5 new known open source security vulnerabilities in March.

#1 libssh2

CVE-2019-3855

Vulnerability Score: High — 8.8

Affected versions: all versions up to and including 1.8.0

CVSS v2.0 - 9.3

According to the libssh2 security advisory, “a malicious server could send a specially crafted packet which could result in an unchecked integer overflow. The value would then be used to allocate memory causing a possible memory write out of bounds error (CWE-130).” According to the advisory, there are currently no known exploits of the vulnerability

For remediation, the libssh2 advisory recommended updating to libssh2 version 1.8.1 or later, or applying the patch they created.

libssh2, not to be confused with libssh, is a client-side C library implementing the SSH2 protocol, available under the revised BSD license. The project is supported by an active community — according to the stats, it has averaged 2.6 commits per average day, with a total of 2,019 commits on GitHub.

libssh2 did some deep spring cleaning this month, and has published a number of additional security integer overflow vulnerabilities, and also out of bounds read issues in all versions prior to 1.8.1. Lucky for us, libssh2 has already provided fixes for them.

Other integer overflow issues that could lead to an out of bounds write, include CVE-2019-3856, where an integer overflow issue was discovered in the way keyboard prompt requests are parsed. In addition, we have CVE-2019-3857, where an integer overflow issue discovered in the way SSH_MSG_CHANNEL_REQUEST packets with an exit signal were parsed.

Then, we also have a few highly critical out of bounds reads issues that could be exploited to cause a Denial of Service or read data in the client memory. Let’s start with CVE-2019-3858 where an out of bounds read flaw was discovered when a specially crafted SFTP packet was received from the server. In CVE-2019-3859, which got a whopping 9.1 CVSS v3.0 vulnerability score, an out of bounds read flaw was discovered in the _libssh2_packet_require and _libssh2_packet_requirev functions. Another libssh2 issue published and fixed in March is CVE-2019-3860, where an out of bounds read flaw was discovered in the way SFTP packets with empty payloads were parsed. Next is CVE-2019-3861, with an out of bounds read flaw in the way SSH packets with a padding length value greater than the packet length were parsed. In CVE-2019-3862, an out of bounds read flaw was discovered the way SSH_MSG_CHANNEL_REQUEST packets with an exit status message and no payload were parsed. And finally, CVE-2019-3863, where a server could send multiple keyboard interactive response messages whose total length were greater than unsigned char max characters could be used to cause an out of bounds memory write error.

The hardworking folks at libssh2 have already provided fixes for all of these issues. You can read more about the vulnerabilities and their remediation here and here.

#2 WordPress

CVE-2019-9787

Vulnerability Score: High — 8.8

Affected versions: prior to 5.1.1

A critical Remote Code Execution issue was found in vulnerable versions of WordPress. According to the WordPress Release Announcement for version 5.1.1, this was a result of the way comments were being filtered and then stored in the database. The release announcement explained that “With a maliciously crafted comment, a WordPress post was vulnerable to cross-site scripting.”

The issue was discovered by Simon Scannell of Ripstech Technologies, who published a detailed explanation of his research, and received glowing accolades from the open source giant.   

According to Scannell, the vulnerability allows hackers to “take over any WordPress site that has comments enabled by tricking an administrator of a target blog to visit a website set up by the attacker.” Scannell goes on to cite WordPress’s downloads page and warns that over a third of all websites use WordPress. “Considering that comments are a core feature of blogs and are enabled by default, the vulnerability affected millions of sites,” he says in his report.

According to WordPress’s release announcement, the issue was fixed in version 5.1.1, and updated versions of WordPress 5.0 and earlier are also available for any users who have not yet updated to 5.1.

You can read more about the security vulnerability’s fix here and here.

#3 JS-YAML

WS-2019-0032, WS-2019-0034

Vulnerability Score: Medium — 5

Affected versions: All versions prior to 3.13.0

The affected versions of JS-YAML are vulnerable to Denial of Service attacks. Parsing a carefully-crafted YAML file causes the node process to stall, which might exhaust system resources and lead to a Denial of Service.

JS-YAML is a YAML 1.2 parser and writer for JavaScript. It’s an implementation of YAML, a human-friendly data serialization standard for all programming languages. According to JS-YAML’s GitHub and npm pages, the project started as PyYAML port, and was completely rewritten to become very fast, and support 1.2 spec. The 14,589,603 weekly downloads, and 7,322 dependents featured on JS-YAML’s npm page say that users are happy with it.

You may have noticed that the JS-YAML security vulnerabilities have a WS prefix before their ID number. This is because they haven’t been added to the NVD yet. While the NVD is a popular database for security vulnerabilities and includes many open source issues, some open source vulnerabilities that are discovered and remediated by the open source community are published on other various public platforms. This is what happened with the JS-YAML vulnerabilities, and they were added to the WhiteSource database before they were indexed in the CVE or added to the NVD.

According to the npm security advisory that published this vulnerability, upgrading your JS-YAML version to 3.13.0 should resolve the issue.

#4 Linux kernel

CVE-2019-2024

Vulnerability Score: Medium — 5.5

Affected versions: prior to 4.16

This is certainly not the first time that a Linux kernel vulnerability features in our monthly top 5 open source vulnerabilities list, and considering how big and active that community is, we’re sure it’s not the last time.

The vulnerability discovered this past month could allow a local attacker using a specially crafted file to execute arbitrary code within the context of a privileged process.

While the issue already has a CVE ID number, the number is reserved, but no details regarding the security vulnerability have been added yet. However, another large open source community project that goes by the name of Android has published the details of this issue, as earlier provided on the Linux kernel git. This is another case where limiting our open source vulnerabilities intelligence to the NVD might cost us.

To read more about the issue and its fix here on GitHub and on the Android Security Bulletin here.

And if you want to read more about other Linux kernel vulnerabilities you can read about the top 5 Linux kernel Vulnerabilities of yesteryear, and the top 10 Linux kernel vulnerabilities of all time.

#5 safer-eval

WS-2019-0023

Vulnerability Score: Medium — 5

Affected versions: prior to 1.3.2

In more news sourced from the open source community, rather than the NVD, a Remote Code Execution issue was discovered in vulnerable versions of safer-eval, due to Sandbox Escape. According to the npm security advisory,  a payload using constructor properties can escape the sandbox and execute arbitrary code.

The advisory recommends users update to version 1.3.2 to fix the issue.

safer-eval documentation boasts that the project offers “a safer approach for eval in node and browser.” JS coders know that putting “safe” and “eval()” together in a sentence might open a Pandora’s box of coder contention. While some have deemed eval() as a bad part of JavaScript, others suggest that eval is not evil if you know how to use it.

We’re going to elegantly step away from that heated debate and simply recommend that if you check whether you are using a vulnerable version of safer-eval, and make sure you continue tracking your open source components for known vulnerabilities.

Read more about the vulnerability, and its fix on GitHub.

Spring Forward With Your Open Source Vulnerability Management

March’s top 5 new open source security vulnerabilities list provides us with some prime examples of how the open source security ecosystem works, and the challenges of maintaining secure open source components.

The first thing the list clearly demonstrates is that just because a project is large and well maintained by an active community, that doesn’t mean it’s vulnerability-free. Usually, it means that the community is continuously working to resolve any new issues and release fixes and updated versions. That means that users need to keep track of their open source components to ensure that the versions they are using are safe.

The second reminder that stands out in this list is that following only the NVD and nothing but the NVD will only get you so far, since the open source community’s resources expand beyond it. The best way to address both of these issues when addressing open source security is to continuously track your software projects throughout the development lifecycle, to make sure that you know about any vulnerable open source components in your code, as soon as the vulnerabilities are discovered. Spring cleaning is an age-old tradition, and directing it towards outdated and vulnerable open source components involves so much less dust than spring cleaning in the real world. Sounds like a win-win-win to us.

Want to catch up on open source vulnerabilities which could have slipped by in 2018? Check out our top open source vulnerabilities page to see if there are any that you might have missed last year.

See you next month when we pull together the top list for April.

 
Previous Article
Top 5 Open Source Vulnerabilities for April 2019
Top 5 Open Source Vulnerabilities for April 2019

Next Article
The Top 10 Linux Kernel Vulnerabilities You Should Know
The Top 10 Linux Kernel Vulnerabilities You Should Know