Not Particularly Mortifying: IEEE eggheads probe npm registry, say JavaScript libs not as insecure as feared
(2020/09/25)
- Reference: 1601064182
- News link: https://www.theregister.co.uk/2020/09/25/npm_security_risks/
- Source link:
For the past few years, the security of JavaScript software packages available through the Node Package Manager, or npm, has been the subject of skepticism as a result of blunders, brouhahas, and tepid countermeasures.
But several computer scientists affiliated with the IEEE say that npm packages aren't really as risky as has been suggested.
In a [1]paper titled, "On the Threat of npm Vulnerable Dependencies in Node.js Applications," distributed through ArXiv, boffins Mahmoud Alfadel, Diego Elias Costa, Mouafak Mokhallalati, Emad Shihab, and Bram Adams argue that the dangers of integrating npm libraries into Node.js applications are overstated.
The npm Registry stores software libraries or packages that developers add to apps based on Node.js to implement specific functions. It exists so developers don't have to reinvent the wheel every time they want, for example, to add a routine for pulling URLs from blocks of text; they can just install the URL-grabbing code, via the npm command-line interface, that some other developer wrote and uploaded to the npm Registry.
The registry hosts around 1.4 million packages, and if the security risks of relying on unaudited third-party code aren't sufficient to set off alarm bells, consider that many of these packages depend on other npm packages. So a coding error or a malicious commit in one of these libraries has the potential to affect dependent libraries and all the apps that require a vulnerable package.
Examples of how things have gone wrong include the tampering with npm's [2]event-stream module in 2018 to make it steal cryptocurrency, a similar situation that arose with [3]electron-native-notify last year, and the [4]left-pad debacle in 2016.
If you want to hijack widely used JavaScript packages, try phishing for devs through these DMARC-shaped holes in key Node.js domains [5]READ MORE
The security challenges facing NPM, Inc, the company managing the npm ecosystem, were further complicated by financial resources that didn't keep pace with its popularity, at least until it was [6]purchased by Microsoft's GitHub earlier this year.
Node.js's problems, security and otherwise, even prompted Ryan Dahl, creator of Node.js, to develop a successor runtime called [7]Deno that attempts to provide a better security model, among other improvements.
Yet, the IEEE boffins, after analyzing 6,673 actively used Node.js apps, have found the security situation is not quite as bad as security vendors claim. There are a lot of vulnerabilities in npm packages but most are not that severe.
"Our findings show that although 67.93 per cent of the examined applications depend on at least one vulnerable package, 94.91 per cent of the vulnerable packages in those affected applications are classified as having low threat," they said in their paper.
What's more, among the few apps with high threat dependencies (3.03 per cent), the vast majority (90.8 per cent) had fixes available that had not been applied.
The boffins suggest that the fault here should be assigned to app developers, for not updating their app dependencies to the latest, safest versions, rather than the package maintainer.
"[A] major implication of our study is that application developers need to take updates pushed from their dependencies seriously, or at least actively track their dependencies, since those can lead to very serious effects," the paper concludes. ®
Get our [8]Tech Resources
[1] https://arxiv.org/abs/2009.09019
[2] https://www.theregister.com/2018/11/26/npm_repo_bitcoin_stealer/
[3] https://www.theregister.com/2019/06/07/komodo_npm_wallets/
[4] https://www.theregister.com/2016/03/23/npm_left_pad_chaos/
[5] https://www.theregister.com/2020/08/25/nodejs_dmarc_phishing/
[6] https://www.theregister.com/2020/03/16/microsofts_github_npm/
[7] https://www.theregister.com/2020/05/14/nodejs_creator_deno_10/
[8] https://whitepapers.theregister.com/
But several computer scientists affiliated with the IEEE say that npm packages aren't really as risky as has been suggested.
In a [1]paper titled, "On the Threat of npm Vulnerable Dependencies in Node.js Applications," distributed through ArXiv, boffins Mahmoud Alfadel, Diego Elias Costa, Mouafak Mokhallalati, Emad Shihab, and Bram Adams argue that the dangers of integrating npm libraries into Node.js applications are overstated.
The npm Registry stores software libraries or packages that developers add to apps based on Node.js to implement specific functions. It exists so developers don't have to reinvent the wheel every time they want, for example, to add a routine for pulling URLs from blocks of text; they can just install the URL-grabbing code, via the npm command-line interface, that some other developer wrote and uploaded to the npm Registry.
The registry hosts around 1.4 million packages, and if the security risks of relying on unaudited third-party code aren't sufficient to set off alarm bells, consider that many of these packages depend on other npm packages. So a coding error or a malicious commit in one of these libraries has the potential to affect dependent libraries and all the apps that require a vulnerable package.
Examples of how things have gone wrong include the tampering with npm's [2]event-stream module in 2018 to make it steal cryptocurrency, a similar situation that arose with [3]electron-native-notify last year, and the [4]left-pad debacle in 2016.
If you want to hijack widely used JavaScript packages, try phishing for devs through these DMARC-shaped holes in key Node.js domains [5]READ MORE
The security challenges facing NPM, Inc, the company managing the npm ecosystem, were further complicated by financial resources that didn't keep pace with its popularity, at least until it was [6]purchased by Microsoft's GitHub earlier this year.
Node.js's problems, security and otherwise, even prompted Ryan Dahl, creator of Node.js, to develop a successor runtime called [7]Deno that attempts to provide a better security model, among other improvements.
Yet, the IEEE boffins, after analyzing 6,673 actively used Node.js apps, have found the security situation is not quite as bad as security vendors claim. There are a lot of vulnerabilities in npm packages but most are not that severe.
"Our findings show that although 67.93 per cent of the examined applications depend on at least one vulnerable package, 94.91 per cent of the vulnerable packages in those affected applications are classified as having low threat," they said in their paper.
What's more, among the few apps with high threat dependencies (3.03 per cent), the vast majority (90.8 per cent) had fixes available that had not been applied.
The boffins suggest that the fault here should be assigned to app developers, for not updating their app dependencies to the latest, safest versions, rather than the package maintainer.
"[A] major implication of our study is that application developers need to take updates pushed from their dependencies seriously, or at least actively track their dependencies, since those can lead to very serious effects," the paper concludes. ®
Get our [8]Tech Resources
[1] https://arxiv.org/abs/2009.09019
[2] https://www.theregister.com/2018/11/26/npm_repo_bitcoin_stealer/
[3] https://www.theregister.com/2019/06/07/komodo_npm_wallets/
[4] https://www.theregister.com/2016/03/23/npm_left_pad_chaos/
[5] https://www.theregister.com/2020/08/25/nodejs_dmarc_phishing/
[6] https://www.theregister.com/2020/03/16/microsofts_github_npm/
[7] https://www.theregister.com/2020/05/14/nodejs_creator_deno_10/
[8] https://whitepapers.theregister.com/
Re: Phew! We're safe then!
Glen 1
See also: Flatpak and Snap
Not even one in ten
Doctor Syntax
I'm not sure whether this counts as damning with faint praise or praising with faint damns.
Phew! We're safe then!
I recently had to try and package up the latest CLI for 'Box' cloud storage so it could be deployed into a secure environment with restricted internet access.
Although it's maybe an impressive feature of npm that it warns you about security bugs, after it had pulled in well over 200mb of JavaScript files in the form of well over a thousand dependencies, it warned me that the current package was vulnerable to something like 800 known CVEs! (I forget the exact number - maybe it was 300 and I'm exaggerating but 300 or 800: the point still stands that this is utterly insane).
There was an auto fix option which got part way through, borked the package, bombed out with a stack trace (if I recall correctly) and ultimately decided that the bugs could be automatically reduced to under 100 but to go further would require upgrading various dependencies through potential breaking changes. Sure, some responsibility has to fall of the vendor of the CLI code in question, but this problem is endemic in the general approach to software using such tools.
I had to stick with it in its native form, warts and all. I was not at all happy about letting that near a secure environment but with some damage limitation measures it seems to be workin, at least.
It's not just nodeJS though. Certainly it gets its fair share, but so many other languages are encouraging this super-convenient (when it actually works) but highly risky approach of automatically downloading vast numbers of interdependent libraries from a similarly vast number of sources.
For me the very worst part of all of them is the fact that they all assume you have an internet connection and make it anywhere from difficult to impossible to build using simple local mirrors or to package up a complete set of everything needed to reliably run the application fully offline.
People look at me like I'm mad when I suggest using a minimal set of carefully vetted external libraries whilst maximising the use of built in features of the chosen language and avoiding automated dependency resolvers like the plague... It certainly takes a bit more effort but you then end up with, let's say, a command line interface to a rest service which might be just a few megabytes in size instead of nearly 300mb, with only one or two external libraries if any at all - simple enough to audit, limited in function to pretty much only what it was designed for (How many times do Devs call in massive library X to use one single function out of hundreds!?), will run anywhere it's installed and is generally easy to debug.
I'm not saying we should start reinventing the wheel every time, and it's clearly safer to use tried and tested code for things like encryption. But I am saying there's a balance between writing some bespoke code which happens to duplicate some functionality of a massive external library, and downloading half the ecosystem of your chosen language just parse a config file or open a damn socket. In my opinion npm and the likes go waaaay too far off the scale.