Earlier this year, the popular Bower package manager was found vulnerable to archive extraction, allowing attackers to write arbitrary files on a user's disk. As Nodejs Security WG member and Snyk developer advocate Liran Tal wrote, the vector attacks used by this exploit have been known since the early days of BBS.
As security researcher skyn3t reported on January 1st 2019, an attacker could craft a malicious zip archive to exploit improper validation of symlinks to write arbitrary files outside of the zip extraction directory. According to Tal, the culprit for enabling path transversal in Bower's case is a small Nodejs package, decompress-zip, but it is far from being an isolated case. In fact, this kind of vulnerability has been found in several ecosystems, including JavaScript, Ruby, .NET, Go, and Java, and seems to affect thousands of projects, making it deserve the ZipSlip moniker. What is even more striking is that the basic attack vector used by ZipSlip has been known, and potentially exploited many times, since the very early days of Bulletin Board Systems (BBS).
InfoQ has taken the chance to speak with Tal to learn more about software securit,y and Nodejs security in particular.
InfoQ: Could you introduce yourself and shortly describe what you do at Snyk?
Liran Tal: I’ve been a software developer for a while now, and in the recent five years or so I had taken the role of leading web development teams as an engineering manager. I joined Snyk as a developer advocate in a mission to help other developers use open source and stay secure, and further broaden my work around the security of the Node.js and JavaScript ecosystem. It’s a great story with Snyk, because I’ve known the people there and have been using snyk for a couple of years back in several of my former workplaces.
InfoQ: Global statistics show that software vulnerabilities have been steadily growing during the last few years, affecting software systems from their basic components (CPUs, OSes, networking stacks, etc.) up to user-facing apps, making it possible to steal user data at a unprecedented scale. Is this a matter of our systems getting more vulnerable, growing too much in terms of complexities, or the beneficial effect of greater awareness of the importance of security?
Tal: I think it’s a little bit of everything you mentioned. Systems are undoubtedly becoming more complicated, and we see many more abstractions today than we have two decades ago. It’s not to say that this is bad, but it adds complexity and increases the skill and expertise required.
Systems aren’t intentionally becoming more vulnerable, but as I’m sure all developers can relate - the more code we add, the higher the risks of bugs and security vulnerabilities. The immense adoption of open source software in the recent decade is amazing and truly heart-lifting for anyone who's been in the scene since the early days of the open source software movement. At the same time, it means we build our products using software components built by potentially many developers, or say, strangers, which we don’t have any insights into their security know-how, or how often they have audited their code-bases, if at all.
I’m actually happy you brought up this topic because I’ve been working in the last several weeks to build a report which sheds light and actual numbers about the state of open source security. It looks at application libraries, system libraries, and the posture of open source developers and maintainers. We learned some interesting things about security aspects in developers code-bases, such as how do they find out about a security vulnerability, and how many of them include automated security testing in their CIs. Snyk released this report last year as well and the new 2019 report will be out in a few weeks.
Overall, I believe E.S Raymond correctly coined that given enough eyeballs, all bugs are shallow. GitHub as a platform makes the barrier for participating in open source communities extremely low, which is in my opinion, a big contribution to the adoption of open source. It makes it relatively easy for code-bases to undergo security scrutiny, and engage with the maintainers with regards to vulnerabilities and fixes. That said, an interesting metric we gathered from last year’s report is that the maximum time it took for a vulnerability introduced into the codebase to be disclosed is 5.9 years. That’s a huge amount of time for a vulnerability to live dormant in source code until someone finds out about it and discloses it. The median time is 2.5 years for some of the popular libraries we researched on this.
InfoQ: Speaking of NodeJS, your area of expertise, you have recently covered a vulnerability in Bower, a package manager still in wide use today. What is still of greater concern is the security status of NPM, the leading package manager for the NodeJS/JavaScript ecosystem. What should developers do to minimize the risk of shipping vulnerable software?
Tal: Issues are so widespread that tackling them might appear daunting. When it comes to npm security, there are two aspects of that - the security of the npm registry itself and its platform for developers and maintainers. The former has been criticised in the past with regards to whether it is implementing adequate measures to provide a secure foundation for the ecosystem to build upon. The latter is the level of security found in the collection of JavaScript source-code that is hosted on the npm registry.
Shifting security to the left as much as you can is a great start to take security seriously. To begin with, it’s a security mindset and the understanding that security is everybody’s job, as Tanya Janca says. Embracing security concerns as part of your design and code-review processes, and then continuing to integrate a good set of processes and tooling that supports it within your everyday development workflows.
Some examples are adopting static code analysis plugins as part of your build process, or scanning your project for vulnerabilities in open source dependencies, which Snyk does best due to its comprehensive vulnerabilities database as well as it’s pro-active approach of not only reporting vulnerabilities, but also automatically opening Pull-Requests with the minimal semver change required to upgrade a dependency.
Security doesn’t stop there with just a CI integration to scan for vulnerabilities. Take the following situation - you develop a web application, ship it to production vulnerability-free, and move on to the next project. That source source is unmaintained, but as we learned with the recent report and years of security experience, vulnerabilities will surface later on. How do you know about that? You need to also monitor your project’s dependencies through time so that if a security issue was found, you can get back to the project and attend to a fix. This is something that is built-in to snyk and its holistic approach to being integrated into the entire software development lifecycle.
An interesting fact of the Bower vulnerability that you mentioned previously - it is related to research that the security team at snyk has done last year, and has been first mentioned in a Phrack article some twenty years ago. The research uncovered thousands of projects being vulnerable to a badly implement behavior in zip archives that can result in arbitrary file writes and potentially remote code execution. This further shows the impact of using open source software, where-as a vulnerability in one library, can manifest in thousands of projects and code-bases.
As you can imagine, a supply chain service such as npm, yarn, or Bower, all have to do something related with archives and Bower was specifically found to be vulnerable to several types of Zip Slip vulnerabilities. If anyone is interested in the proof-of-concept to how that works I covered the story and the technical step by step instructions on this exploitation.
InfoQ: Is there some effort that should be undertaken at a more structural level, within the NodeJS ecosystem?
Tal: From the Node.js perspective, the Security working group has been tasked with several areas of responsibility to help create a more secure ecosystem for Node.js, and indirectly for the whole JavaScript ecosystem as well.
We are actively working to review and improve security focus such as related Node.js APIs, secure code-review and security testing for Noe.js core. The working group is also acting as an incidents response team for both the third-party ecosystem modules on the npm registry, as well as Node.js core.
There are several external efforts to provide the community with security knowledge, and insights such as the Node.js Security Roadmap, and efforts to consolidate security resources such as my own awesome-nodejs-security resource. We will hopefully see more of that from within the Security WG as well.
Many different efforts and initiatives exist to improve the security of the Node.js ecosystem and InfoQ will continue to report about them and keep you timely informed.
