The holiday season is upon us. Hopefully by this time we’ve all emerged from our food coma, and braved Black Friday and Cyber Monday mayhem in time to start developing some Christmas cheer. While everyone has been getting at their holiday shopping lists, our hardworking research team carved out some time to study the Mend database and find the top five new open source security vulnerabilities in November.
The Mend vulnerability database collects all of the open source security vulnerabilities published in various community resources, including the National Vulnerability Database (NVD), security advisories, and issue trackers. The database provides comprehensive information on open source security vulnerabilities disclosed throughout the community.
November’s list of top five new open source vulnerabilities includes some of the most popular platforms, frameworks, and tools in the software development ecosystem. So hang on to your Santa hats, and take a look at these new issues, since you’re most probably using at least some of them.
Vulnerability Score: High — 7.5
Affected versions: Python 2.7.11 / 3.6.6.
This first high-severity issue comes from the open source community’s favorite Python. A denial of service vulnerability was discovered in the X509 certificate parser of Python.org. As a result, a specially crafted X509 certificate can cause a NULL pointer dereference, leading to a denial of service. Hackers could exploit this issue by using crafted certificates.to initiate or accept TLS connections.
Python has been extremely popular in the open source community for years, ranking third in GitHub’s annual report “The State of the Octoverse” for the past few years. This year it made a leap to second place, replacing Java. Python’s security profile is generally solid, with a relatively low percentage of high-severity vulnerabilities over the past ten years, and a consistent decrease in vulnerabilities overall since 2015. If you’re one of Python’s continuously growing community of users, it’s best to make sure that you are using a secure version.
You can find more information about the vulnerability here.
Vulnerability Score: Medium — 6.5
Affected versions: all versions before samba 4.11.2, 4.10.10 and 4.9.15
According to Samba’s security advisory, Samba client code (libsmbclient) returns server-supplied filenames to calling code without checking for pathname separators like “/” or “../” in the server returned names. The NVD description explains that “An attacker could use this vulnerability to create files outside of the current working directory using the privileges of the client user.”
The advisory warns that users of the libsmbclient library external to Samba might also be vulnerable if they use server returned filenames without checking, and pass them to functions that can access local filesystem.
Happily, the advisory also provides patching and remediation info. Patches can be found on the Samba Security Releases page, and Samba versions 4.11.2, 4.10.10, and 4.9.15 have been issued as security releases to correct the issue. The advisory recommends Samba administrators to upgrade to these releases or to apply the patch as soon as possible.
Samba is an OG in the open source community, and has been around since the early 90’s. It’s an implementation of the SMB protocol and the related CIFS protocol that allow PC-compatible machines to share files, printers, and information. SMB/CIFS protocols are used by many clients, including all versions of DOS and Windows, OS/2, Linux and more, so if you’re an admin in an organization of any size, it’s best you check your Samba version and make sure that it is up-to-date.
Read more about this security issue and its fix.
Vulnerability Score: High — 7.5
Affected versions: before v5.1.0b1.
Vulnerability Score: Medium — 6.4
Affected versions: v3.1.0 through v4.2.0
This first issue is WS-2018-0603, and it could potentially be remotely exploited to allow Denial of Service.
Luckily, the issue has been remediated by the Tornado team, so all you need to do is make sure that you aren’t using a version prior to v5.1.0b1.
You can find out more about the vulnerability and its fix on GitHub.
Then, we have WS-2015-0057, a path traversal issue, with a medium vulnerability score of 6.4, in versions: v3.1.0 through v4.2.0. According to the commit description on GitHub, the StaticFileHandler in vulnerable versions allowed access to files whose name starts with the static root directory, instead of allowing access only to the files in the directory.
This issue has already been addressed by the Tornado team, so all you need to do is make sure that you’re using a secure version.
According to their user's guide, which is also open source and welcomes edits on GitHub, Tornado can scale to tens of thousands of open connections, making it ideal for long polling, WebSockets, and other applications that require a long-lived connection to each user.
You might have noticed that these two issues don’t have the more common CVE prefix at the beginning of the index number. That’s because while the NVD is a large and well-known vulnerabilities database, it doesn’t cover all of the known security vulnerabilities out there. When it comes to the open source community, issues can be discovered and addressed within the community, without necessarily being included in the NVD. This is what happened in the case of these two issues in older versions of Tornado. Even though it’s not in the NVD, it is included in the Mend database, which aggregates and analyzes data from numerous community resources, and that’s how these vulnerabilities got a WS prefix.
Vulnerability Score: Critical — 9.8
Affected versions: before 9.0.20, 9.1.x before 9.1.16, 9.2.x before 9.2.11, 9.3.x before 9.3.7, and 9.4.x before 9.4.2
According to PostgreSQL’s release announcement, this vulnerability was caused by “unanticipated errors from the standard library.” The NVD provides a bit more details, explaining that the snprintf implementation in vulnerable versions of PostgreSQL doesn’t handle system-call errors properly. Hackers could exploit this to get sensitive information.
This isn’t the first time that PostgreSQL is included in our monthly top 5 new open source vulnerabilities post, and that’s because it appears to be gaining more users every day. This is the second consecutive year that PostgreSQL is the fastest growing database in the world. Postgre’s firm hold on this first place title, along with the backing of an active and dedicated community over the past thirty years means that there’s a good chance you’re using PostgreSQL.
Postgre’s hardworking community released updated versions to address this and a few other issues, and it’s a good time to update to one of their recent security releases.
Vulnerability Score: High — 8.8
Affected versions: OS X prior to 76.0.3809.87
Uh-oh. While MacOS users often boast about the heightened security of their products, it appears the Google Chrome team has made a sweep, with a lot of help from their bug bounty program. A nice batch of issues was discovered, including a few that impact some beloved Apple products.
In the case of this high-severity issue, flawed security UI in MacOS services integration in vulnerable versions of Chrome on OS X could be exploited by a local attacker to execute arbitrary code via a crafted HTML page.
A total of 16 security issues were published in the Chrome 76 release update. Thanks to the community, all these have been addressed, and now we can make sure we’re updating our Google versions to stay secure.
From the second most popular programming language to the fastest growing database, and the world’s most popular browser, November’s list of top 5 new open source security vulnerabilities proves once again that the most common tools that we use for development rely on open source, and that there’s a strong chance that if we don’t track and update those components regularly, they contain a security vulnerability.
Whether it’s generous bug bounties or a loyal and active community, the maintainers of the open source projects in the November top five list are working hard and doing a great job at detecting and addressing security issues in their projects. That leaves us with the responsibility of making sure that we have as much control and visibility as possible over the open source components that we’re using so that we can address any security vulnerabilities as soon as possible.
Want to catch up on earlier open source vulnerabilities in 2019? Check out our top open source vulnerabilities page to see if you missed anything.
See you in 2020 when we pull together the top list for December. Until then, make sure to keep the holiday spirit alive with plenty of eggnog, and don’t forget to track your open source components.