Nope, because the script was commited to upstream and you can review what ended in the package.
It seems a lot of general "wisdom" here is thrown by people who have not looked into this particular incident or are unfamiliar with js node dev in general.
Correct, luckily, but all it takes is one eval. So be diligent about checking. However, like you said, luckily it’s JavaScript and there’s a history online that you can see.
Be weary of binary wasms though, harder to analyze. In the end, because it was published and npm allows you to see the history, we can all see.
Still, from a security standpoint, anything within a “package” that is compromised, compromises the package. Don’t install it. Wait for the fix.
Create a blog post about a security issue. Post it on HN and get upvotes. Find people who believe they might be affected. Let them run the affected program. Boom.
Comments
Are you affected? Run the affected program. OK, now you are definitely affected.
Says the malware is in a post-install script - that will not be called by nx, but i.e after an npm install
Consider anything pre or post attached to the package as tainting the package.
Consider your entire system tainted, nothing is trustworthy at this point. Wipe and rebuild from known good media.
The malware is "luckily" written in javascript and such quite easy to analyse. No manipulation outside of .zshrc or .bashrc and a temp txt file.
That's what the code you can see now does. It may or may not be the same as what ran.
Nope, because the script was commited to upstream and you can review what ended in the package.
It seems a lot of general "wisdom" here is thrown by people who have not looked into this particular incident or are unfamiliar with js node dev in general.
Correct, luckily, but all it takes is one eval. So be diligent about checking. However, like you said, luckily it’s JavaScript and there’s a history online that you can see.
Be weary of binary wasms though, harder to analyze. In the end, because it was published and npm allows you to see the history, we can all see.
Still, from a security standpoint, anything within a “package” that is compromised, compromises the package. Don’t install it. Wait for the fix.
WASM should be easier to analyze since you can't look at what functions the WASM imports to do side-effects.
Oh good. I guess running the actual program was too many steps.
It might be even better than that:
Create a blog post about a security issue. Post it on HN and get upvotes. Find people who believe they might be affected. Let them run the affected program. Boom.
Either I've grown old and bitter enough that I think this is likely the case, or this is just a rational take and most likely what happened.
I'm not sure which is worse.