But you can just curl it again in a few minutes and bring it down again. And then again after that, so they claim that it can be done indefinitely. That’s quite a big difference.
Also, you can target not just express but an even higher volume small library that most large projects depend on.
I don’t get how every comment so far has dismissed DoS as a serious issue.
On it's own probably not. Given the way that people hook npm into automated deployments it likely can rise to that level for some users. Given that some people may depend on this deployment strategy without even being aware of it, it does seem like an issue worth noticing.
TLDR: A Denial-of-Service vulnerability triggered via cache poisoning on registry.npmjs.org which can render individual packages inaccessible
I don't see the big security impact that the headline suggests, as active big-scale exploitation would likely be quickly noticed and fixed.
The most interesting attack vector IMHO would be to block individual security fixes to packages on a small scale.
Perhaps, but it could also be fixed/mitigated by cycling the cache state and blocking bots. It might also be something that can be blocked in a web proxy.
It's interesting, but I share the thought that the impact is overstated.
13 comments
[ 3.8 ms ] story [ 40.6 ms ] threadAlso, you can target not just express but an even higher volume small library that most large projects depend on.
I don’t get how every comment so far has dismissed DoS as a serious issue.
I don't see the big security impact that the headline suggests, as active big-scale exploitation would likely be quickly noticed and fixed. The most interesting attack vector IMHO would be to block individual security fixes to packages on a small scale.
Fixed as in fixing the exploit that TFA is reporting? Isn’t that the point of their report?
It's interesting, but I share the thought that the impact is overstated.
Ahhh... They're trying to sell themselves as security experts.
There is a lot of JavaScript that does not use npm for good reasons (e.g. this, but also the rest of the disaster that is npm).
Anyway, one properly mad technique shielding against all npm-related problems that I've seen being used was to include node_modules in the repo.
Terrible, yes, but was a real life-saver when the left-pad issue hit.
Terrible, yes, but was a real life saver
[1] https://yarnpkg.com/features/caching#offline-mirror