Closed radmen closed 4 years ago
Hi 👋
Thanks for chiming in and hope the article was a valuable insight. TLDR; none of these is an expected source of concern for lockfile-lint, see below for elaborate explanation.
To address your scenarios:
An action item that I'm thinking about with regards to the issues raised above is that perhaps these need to be better documented, so I'm happy to get a PR to update the README with said security disclaimer pointing out these risks which this package doesn't address at this point.
P.S. I believe a false sense of security
is a bit aggressive so I updated the title and reflected it in your own words of possible false positives.
P.S. I believe a false sense of security is a bit aggressive so I updated the title and reflected it in your own words of possible false positives.
I'm sorry, I didn't mean to sound harsh. English is not my native language, and it didn't seem aggressive to me.
npm malicious packages - that's indeed a possible vector of attack, unrelated to the lockfile
I've mentioned a scenario of lock file poisoning - a case where a package is replaced by another directly in a lock file. This is something that might go unnoticed by the user.
It's a scenario that goes way beyond host/protocol checking. It would probably require (IMO) a more in-depth analysis of package.json
contents and comparing them w/ the lock file.
One could also argue that by the time you have a lockfile to lint and if you already installed a malicious package, then linting the lockfile is the least of your concerns.
Isn't this the purpose of this tool? "Lint an npm or yarn lockfile to analyze and detect security issues" (that's what's written at the top of the repo page).
It covers only basic scenarios. Something a bit more complex won't be noticed and the users won't be aware that their lock files might be compromised. I believe that this should be stated in the docs.
npm malicious packages - that's indeed a possible vector of attack, unrelated to the lockfile
I've mentioned a scenario of lock file poisoning - a case where a package is replaced by another directly in a lock file. This is something that might go unnoticed by the user.
Agree, it's a form of poisoning but at the level of the trusted source. To an extent, it is the purpose of the tool, but also there's a scope of how much you're able to scope out and what risk you still have to undertake. Otherwise, you could also argue that even if you lint specific package sources then someone can compromise npm or GitHub themselves to manipulate one version with another too.
Like I said, I'm happy to receive a PR to implement URI-specific whitelisting, or any other ideas you have to improve on the current capabilities, as well as a disclaimer for the README.
I've read the article about this tool and at first all made sense.
Then, I've looked at the examples and realized that it's simple to trick it to report false positives.
I'll give two scenarios.
1. using the example from the article
lockfile-lint
is used with following options (this is the command taken from examples)lockfile-lint
will not report any problems2. Injecting malicious NPM package
lockfile-lint
will not report any problems (the package is hosted by NPM so it should be fine)Quick and dirty example of such you can find on followin Gist: https://gist.github.com/radmen/0e9ce8706343db28f68bc7ad97910ed3
By all means, I'm not a security expert. I just wanted to ask - are those scenarios possible? I find them highly possible and thus I think that this tool might give people false sense of security that everything works fine.