There is an open NPM “audit assertions”[1] RFC which would allow the compromised package to be nested one dependency deeper, and would allow the hijacked ua-parser-JS package to assert that it’s unaffected.
Should this proposal go through, it’s quite possible this would have gone much further. It would have allowed the attacker to wait for detection, and to silence any propagation of that to users of the otherwise legitimate package.
I had to bow out of the conversation because I didn’t feel like I could engage it in a healthy way—I’m way too personally affected by my own experience dealing with dismissal of serious security issues—but I think folks here might be interested in it given this compromise.
A malicious audit assertion is grounds to consider the package malicious. Thus you just mark the parent package as malicious.
Edit: I think your misunderstanding is you're considering "malicious config" and "malicious code" significantly different issues, and arguing malicious config won't be noticed as malicious because it's only malicious in the context of what it enables. I believe this is incorrect. Innocuous seeming usage of a legitimate feature that actually has malicious effect is not a new issue.
Looking at the issue in more detail you were told essentially exactly this.
> A far, far easier version that already exists is: put malicious code directly into an otherwise innocuous package (or as a dependency). No vulnerability warning would exist, and thus there'd be no need for assertions. In other words, your "exploit" is just a more complex way of doing something that has always been possible.
> Once you've trusted a maintainer, you have already completely surrendered any protections to their judgement. If they make a mistake with an assertion, they could also make a mistake with code, or by depending on a package with an unknown vulnerability. Similarly, if they're malicious, they already own you because you depend on their code. This RFC does not introduce any new problems or attack kinds - all it does is add another vector that is more complex and easier to fix than existing ones.
Edit2: Another way of saying it is you're essentially arguing "this feature means that given sufficient control of a popular package to make innocuous seeming but actually malicious changes essentially any compromise is possible", and the proponents of this feature are saying there are already so many ways for that level of access to be exploited this makes no difference.
I don’t regret linking the issue, I hope someone who isn’t going to be as emotionally impacted by it will recognize the risks it introduces. But I regret the energy I’ve spent even trying to get past my own physical pain from nearly two years of burnout being dismissed this way even as I’ve tried to discuss the problem in good faith.
I don’t have energy for this. You, like the people in the issue, are welcome to explain away the similarities between different attack vectors and refuse to imagine how this might present different opportunities. I frankly can’t engage in it anymore. The link is there for people who can.
Is the concern that it will encourage library maintainers to do essentially something analogous to an empty catch block to make the error go away without having to think too hard?
try:
use_thirdparty_library()
except SecurityIssues:
# Make error go away. It's probably fine.
pass
This would then hide the problem instead of letting it noisily bubble up the stack.
One way to view it is that someone writes a package that their expected usage is as a build tool. It uses a library that has a input validation vulnerability. Since they view their tool as build tooling they mark their package as not impacted. Npm audit no longer shows the vulnerability.
Someone uses that build tool in a production system in a way the maintainer never even considered.
Npm audit shows nothing to that end user. They are vulnerable.
People will say they misused the tool. But either way, shit gets compromised and it is something could have been prevented if you take the stance that the end user was paying attention to audit findings.
And yes, many corporations and govt agencies take audit findings seriously. Hiding this because a maintainer said not impacted is scary IMO
And on the other hand every week I see a few issues about "regex DDOS" for tools that usually go nowhere near user-generated input. The signal/noise ratio of NPM audit is very poor, and right now I think its main impact is to pressure people to update often. All of that creates a very fertile ground to distribute malicious code through NPM.
To be fair to the proposal’s advocates and the person who posted the blog article which prompted it: they’re not wrong that npm audit is mostly irrelevant noise and actively harmful (incentivizes individuals to ignore meaningful security issues) because of that. Their proposal is just the wrong solution, and last I checked in they were too wedded to it.
npm audit is pretty damn meaningless at the moment. Creating a bog-standard react app with create-react-app (`npx create-react-app my-app`) right now results in
This is a job posting for a security engineer at npm from July 4, that appears filled to me. I'm sure as an organization npm inc. is aware of vulnerabilities in their core product, so there's internal back and forth - the usual stuff.
Should this proposal go through, it’s quite possible this would have gone much further. It would have allowed the attacker to wait for detection, and to silence any propagation of that to users of the otherwise legitimate package.
I had to bow out of the conversation because I didn’t feel like I could engage it in a healthy way—I’m way too personally affected by my own experience dealing with dismissal of serious security issues—but I think folks here might be interested in it given this compromise.
1: https://github.com/npm/rfcs/pull/422