Some things never change. For starters, February began with Punxsutawney Phil, the hero of Groundhog Day, once again coming out of hibernation to give us his much awaited prediction for the start of spring. No use in sugarcoating it folks, we still have a ways to go. Meanwhile, the open source community didn’t have the luxury of winter hibernation, seeing as new open source vulnerabilities don’t wait for spring.
That brings us to this months top 5 new open source security vulnerabilities, aggregated from the National Vulnerability Database (NVD) as well as our own WhiteSource database, updated daily from a number of open source publicly available, peer-reviewed security advisories.
Some of the projects hit this February have been featured in our previous monthly updates, and some are unfortunate newcomers to the list. The good news is that all of the vulnerabilities have fixes, so without further ado, here are the top 5 new open source vulnerabilities that we should all be checking our projects for.
CVE-2017-1000354 Vulnerability score: High — 8.8
CVE-2017-1000355 Vulnerability score: Medium — 6.5
CVE-2017-1000356 Vulnerability score: High — 8.8
Affected versions: 2.56 and earlier as well as 2.46.1 LTS and earlier
This three-for-one special is handed to us courtesy of our beloved open source CI server.
Continuous Integration has become a fundamental process in the software development environment, and Jenkins — the Java-based, open source CI server, is one of the most popular ones out there. Happy users cite the fact that Jenkins is a cross-platform tool, and that it offers configuration both through GUI interface and console commands. Users also like that thanks to its large open source community, Jenkins offers flexibility, a comprehensive plugin list, and strong community support.
All of the three issues allow for Cross-Site Request Forgery (CSRF) in Jenkins, meaning that hackers could execute various admin actions by tricking a victim into opening a web page.
In CVE-2017-1000354, a login command allowed impersonation of a Jenkins user.
CVE-2017-1000355 is caused by an XStream vulnerability. XStream is a Java library that Jenkins uses to serialize and deserialize XML. The XStream vulnerability in Jenkins could cause Java to crash through a DoS (Disruption of Service) attack.
CVE-2017-1000356 is a vulnerability in Jenkins user database authentication, enabling hackers to create an account on the application, allowing unauthorized disclosure of information and unauthorized modification.
Since the build server is where development teams prepare all of their code for distribution, vulnerabilities that allow attackers to disrupt the processes and even steal code are very risky.
Luckily, the dedicated folks at Jenkins have provided a detailed security advisory with all remediation and version update information.
Vulnerability Score: High — 7.5
Affected versions: prior to 3.17
Even way back in the old days, when the corporates and the open source community were bitter rivals, applications were sometimes required to interact with MS Word or Excel file formats in order to receive or transmit data. This is where the The Apache POI project comes in, providing an API that enables creating, modifying, and displaying writing MS Excel, Word and PowerPoint files using Java. The popular open source library includes classes and methods to decode user data or a file into MS Office documents.
Remote attackers can exploit this vulnerability to perform a Denial of Service (D0S) attack in applications that accept content from external sources. If you use these types of applications, upgrade to an updated version.
You can find more information about the vulnerability and its fix on GitHub.
Vulnerability Score: Low — 3
This time, the security issue affects Firefox, one of the many AngularJS users, where the XSS (Cross-Site Scripting) vulnerability was discovered. This means that users of outdated Firefox browser versions are open to malicious software while visiting a seemingly safe site.
As you can see, this AngularJS vulnerability doesn’t have the common “CVE” ID. This is because it is yet to been added to the NVD database, but has been published in one of the other security advisories scanned by the WhiteSource database, earning it a respectable “WS” prefix on its ID.
Vulnerability Score: Medium — 5.5
Affected versions: Django 2.0 before 2.0.2, 1.11.8 and 1.11.9
Django is another extremely popular web development framework that allows users to create sites more efficiently, in a structured and organized way. Django is supported by a large and active community, boasting over 25,000 commits and over 1500 contributors to date.
One of the reasons Django is a go-to for so many developers is that it does a lot of the heavy lifting for them,using a standard format. That means developers don’t need to rebuild every website from scratch.They get the skeleton and then they just need to flesh out the details.
The vulnerability that was discovered lies in one of django’s login methods, and could allow remote attackers to obtain sensitive information. This is extremely risky due to the fact that Django has a standard convention for logins, and since every Django app depends on the same login component. Once a vulnerability is disclosed, it becomes an easy target for hackers to zero in on and exploit.
Vulnerability score: Critical — 9.8
Affected versions: 2.26 and earlier
Dating back to the early 90’s, glibc (or the GNU C Library) is one of the OGs of free software. It is the GNU Project's implementation of the C standard library, also providing direct support for C++, and indirectly supporting additional languages. The glibc project was started in the early 1990s by the Free Software Foundation (FSF) for their GNU operating system.
The vulnerability that was disclosed in February could result in an integer overflow, and got a scary high 9.8 severity score because this security issue could allow hackers to gain unauthorized disclosure of information, modification, and disruption of service.
Stay Safe: Keep an Eye Out for New Open Source Vulnerabilities
There you have it, our top 5 new open source vulnerabilities is February 2018.
The main takeaway this month is that the popular open source projects aren’t guaranteed to be vulnerability free. More to the point, it is often the larger projects where so many of the vulnerabilities are discovered, for two main reasons. First is that the more code is written for a project, the more chances there are for mistakes. Mo’ code mo’ problems. The flip side of this is that because these projects are so beloved, there really are thousands of eyes pouring over the code, bringing the flaws to our attention.
While we can all agree that they give a developer great value because of the dedicated and active open source community behind them, their popularity and active community also mean that versions are updated continuously, and as users we need to stay on top of vulnerabilities that might come up, and their fixes, to ensure we are always one step ahead of the hackers.
So – until next month’s top 5 update, stay safe and patch your open source vulnerabilities.