May brought us the full bloom of spring, a long Memorial Day weekend, and some nasty open source vulnerabilities, along with just a touch of drama in the open source community.
Now that May is behind us, our hard-working Knowledge Team braved the spring allergies and put together our monthly list of top new open source security vulnerabilities in May, aggregated by our very own WhiteSource open source vulnerabilities database.
The WhiteSource database continuously collects known open source security vulnerabilities from multiple resources like the National Vulnerability Database (NVD), and several other well-respected public, peer-reviewed security advisories, and issue trackers.
Spoiler alert: May’s top 5 list includes vulnerabilities discovered in some of the most widely used open source components out there, and also sheds a bit of light (or shade, if you will) on some of the challenges open source project maintainers have to deal with.
So, here they are folks, hold on to your seats and read all about the top 5 new open source vulnerabilities in May.
Vulnerability Score: Critical — 9.8
Affected versions: from 3.6.0 to and including 3.27.2
A critical security vulnerability was discovered in SQLite3 versions 3.6.0 up to and including 3.27.2. A boundary condition in rtreenode() function, when handling invalid rtree tables, could allow remote attackers to send a specially crafted request to the application, and trigger heap out-of-bounds Read (CWE-125) to crash it.
SQLite is a C-language library that implements an SQL database engine. According to their site, SQLite is the most widely deployed Database Engine in the world, used by all mobile devices, most computers, and countless applications, including Android devices, iPhones, iOS devices, Mac and Windows 10 machines, every instance of Firefox, Chrome, and Safari, every instance of Skype and iTunes, every Dropbox client, PHP and Python, most TV sets and set-top cable boxes, and most automotive multimedia systems.
This is the second SQLite vulnerability disclosed in May, after Cisco Talos published a use-after-free issue (CVE-2019-5018) in the window functionality of version 3.26.0 and 3.27.0. You can read more about it here.
Vulnerability Score: Critical — 9.8 (CVSS v3.0)
Affected versions: before 2.7.51, 2.8.x before 2.8.50, 3.x before 3.4.26, 4.x before 4.1.12, and 4.2.x before 4.2.7
May was quite the month for Symfony, with several vulnerability disclosures and fixes, including two critical vulnerabilities.
The first critical issue, CVE-2019-10910, is related to the Symfony Dependency Injection component. Service IDs from unfiltered user input could allow for SQL Injection and remote code execution.
According to the Symfony advisory, the issue has been fixed in Symfony 2.7.51, 2.8.50, 3.4.26, 4.1.12 and 4.2.7, and a patch is available on GitHub. Note that the advisory reminds users that since versions 3.0, 3.1, 3.2, 3.3, and 4.0 are no longer maintained, no updates were provided for them.
You can read more about the security vulnerability’s fix here.
The second critical issue, CVE-2019-10913, affects the Symfony HttpFoundation component. HTTP Methods provided as verbs or using the override header are not validated but could be treated as trusted input. This could be exploited for SQL injection or XSS.
Coming in with a high vulnerability score of 7.5 is CVE-2019-10911, a vulnerability which could allow a malicious user to authenticate as a privileged user on sites with user registration and remember me login functionality enabled. The community was quick to find and fix this issue as well, as the Symfony advisory details here.
CVE-2019-10912 also got a high severity score, this time 7.1. This issue could allow attackers to cache objects that contain bad user input, resulting in the deletion of files. Here are all the details.
Symfony is a PHP framework for web applications and a set of reusable PHP components. The open source project also sees itself as a philosophy and a community, and considering how popular the project is — it appears many PHP users agree. According to their documentation, Symfony is used by thousands of web applications, including BlaBlaCar.com and Spotify.com, and many popular PHP projects — Drupal and Magento, to name a few.
The Symfony community did a great job this month reporting security issues and creating their fixes. If you’re using a PHP project, please leverage their hard work and make sure that you’re using an updated version.
Vulnerability Score: High — 8.1
Affected versions: before 5.0.8
Vulnerability Score: High — 8.1
Affected versions: before 4.20
Two race condition vulnerabilities leading to a use-after-free that could be exploited by attackers to cause a denial of service and execute arbitrary code were found and fixed in vulnerable versions of the Linux kernel.
The first issue, CVE-2019-11815, affects versions prior to 5.0.8, and was discovered in rds_tcp_kill_sock in net/rds/tcp.c. The issue is related to net namespace cleanup.
You can read more about the vulnerability and its remediation here.
The second issue, CVE-2018-20836,was discovered in Linux kernel versions prior to 4.20. Here, a race condition in smp_task_timedout() and smp_task_done() in drivers/scsi/libsas/sas_expander.c, leads to a use-after-free.
More details about the issue can be found here.
Vulnerability Score: Medium — 5
Affected versions: prior to 1.0.12
Versions of fstream prior to 1.0.12 are vulnerable to Arbitrary File Overwrite. According to the npm security advisory, the fstream.DirWriter() function is vulnerable. Extracting tarballs containing a hardlink to a file that already exists in the system and a file that matches the hardlink will overwrite the system's file with the contents of the extracted file.
Fstream is an extremely popular open source project, currently boasting over 4.7 million weekly downloads from npm. The project offers advanced FS Streaming for Node. The project’s documentation on GitHub describes it as similar to FS streams, but with stat on them, and supporting directories and symbolic links, as well as normal files. They can also be used to set the stats on a file, even if users don't change its contents, or to create a symlink. According to the npm security advisory, upgrading to version 1.0.12 or later should resolve the issue.
This is one of the vulnerabilities in our database with a WS prefix before its ID number, rather than the more common CVE prefix because it has yet to be added to the NVD. While the NVD is a well respected, comprehensive database for security vulnerabilities, and covers most open source issues, some open source security vulnerabilities that are discovered and remediated by the open source community are published on community platforms, as is the case with this fstream issue, which was added to the WhiteSource database before they were indexed in the CVE or added to the NVD.
You can learn more about the security vulnerability and its fix on GitHub.
Vulnerability Score: Medium — 5
Affected versions: prior to 4.1.2
According to the npm advisory, vulnerable versions of ecstatic fail to validate redirects, which could be exploited by hackers to craft requests that result in an HTTP 301 redirect to any other domains.
To remediate, the advisory also recommends that users with ecstatic 4.x, upgrade to 4.1.2 or later, that users of ecstatic 3.x, upgrade to 3.3.2 or later, and that users of ecstatic 2.x, upgrade to 2.2.2 or later.
However, another issue that also needs to be addressed is that the package has been deprecated.
ecstatic is a simple static file server middleware that works with core http, express/connect, or on the CL. ecstatic’s creator and maintainer, frustrated with npm and some ecstatic users, and burnt out after 10 years of building and maintaining this open source project with no sponsorship and very little free time, has had enough. After he decided to stop developing and maintaining the project, he wrote a long and detailed issue on GitHub to spill the truth about why he decided to deprecate the project. And the truth, as is often the case, isn’t pretty.
The story of ecstatic and the multiple reasons that led its creator to discontinue development and maintenance tells us a lot about the current state of the open source community — creators, users, and everything in between. When vulnerable versions of ecstatic were unpublished by npm per the creator's request, it turned out that ecstatic powers quite a few projects, like http-server, which, in turn, are used by some large commercial giants. Some of these users were desperate to get a fixed version and less enthusiastic about actually supporting or backing maintenance and updates. This is just one of the reasons ecstatic’s creator shut it down.
While many industry giants have come to embrace and support the community of open source developers, there are still many countless open source projects that are a labor of love, and mostly maintained by a single developer, whenever they can fit in the tasks around their day jobs. If users don’t start supporting these projects and taking some of the weight off a single developer’s shoulders, we might find ourselves with many more ecstatic-like issues.
ecstatic’s developer was kind enough to offer migration paths to mitigate the deprecation issue. We suggest you check and see if you are using ecstatic or one of its dependents, and find an alternative as soon as possible.
Note that this is another vulnerability not yet listed in the NVD, proving that you need to track more than one source in order to stay on top of security issues in open source components.
May’s list of top 5 new open source security vulnerabilities provides us with a glimpse of the open source eco-system. It includes huge open source projects that have been around since the beginning of FOSS, projects that power many of the apps that we develop and the devices that we use, and widely used projects created and maintained by one driven, hard-working community member.
New issues in well-established components might be published on a number of different sources. With open source components being the basic building blocks of the software industry, we need to be mindful of the varied and non-centralized nature of the community if we want to stay on top of open source components’ vulnerability management.
Today, the only way to keep track of the continuously evolving challenges of open source security is to automatically track all open source components in your software products, address any new vulnerabilities published by the community, and remediate them as swiftly as possible. The open source ecosystem is in a state of constant change. You don’t have time to get ready, you need to stay ready.
Want to catch up on open source vulnerabilities which could have slipped by in 2019? 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 June.