81–90 of 117 posts
Earlier quoted context omitted.
Who's reviewing the software package's dependencies?
Each dependency of a software package would have its own separate set of reviews. Anyone can produce a review using Vouch. Official reviews will also be published in the future.
And yet again, twice in a row this time. Note how the referenced Virustotal result has 40+ detections [1]. I'm still wondering why info like this isn't used by Pypi and NPM. Chocolatey has Virustotal integration for all releases. And it's not like Virustotal is the only option, there is Cape [2] for dynamic execution, Metadefender, and Intezer Analyze just to name a few. Really confusing for such a vital supply chain…
It’s not clear that this would be useful; at least for the coa package, the DLL was downloaded dynamically via a script, so NPM would not have been able to detect it unless the script itself was flagged. Not sure what Chocolatey does, but it’s also hard to threshold on VirusTotal when there are a lot of FPs by random vendors.
We're consuming everything we can about a package to figure this out. We've built a static analysis system to reason about code (it's not perfect, but we're getting better and better). We process all the data we can get, then build analytics, heuristics and ML models to extract evidence. The evidence is then pieced together to identify software supply chain risk.
In this case there is a lot of signal to show both bad and suspicious things are happening.
1. Obfuscation: this creates a comparatively deep AST of the code, and isn't difficult to identify.
2. Command execution: curl, wget, LOLBINs like certutil are pretty easy to identify. This isn't a slam dunk every time you see it, but it adds evidence to a potentially malicious claim.
3. URLs: These are uncommon in libraries and add evidence.
4. Pre/Post install scripts: These are fairly commonly used for other things as well, but invoking node on a source file that is likely obfuscated is a good sign something suspicious is happening.
We're trying to build everything fast enough to make the target far less attractive for attackers before it gets a lot worse.
Earlier quoted context omitted.
> Nothing you will think of will evade defeat. Trust. Why is it that random people can submit packages? Make it so they can't. Only trustworthy people should be able to do that. People who care, so that we don't have to. People we can trust. This is how Linux distributions work and you just don't see malware randomly making its way into official repositories.
I wish it worked that way. I just peeked into how python packages in debian-based distros work. They are most frequently PyPI packages with some debian wrapping, so we're back at the same problem.
These Debian wrappers, however minimal, imply the existence of a maintainer trusted by the Debian community. It's assumed that this maintainer has read the source code and determined it is safe.
Earlier quoted context omitted.
It’s not clear that this would be useful; at least for the coa package, the DLL was downloaded dynamically via a script, so NPM would not have been able to detect it unless the script itself was flagged. Not sure what Chocolatey does, but it’s also hard to threshold on VirusTotal when there are a lot of FPs by random vendors.
Given that these attacks are becoming increasingly common, package registries could at least install each package (prior to publishing) in some isolated container or VM and then run some similar malware detection on the resulting file system. Honestly, I'm strongly considering moving away from the NPM ecosystem because it's clearly become a target for malware.
Earlier quoted context omitted.
But attackers are not dumb. They would circumvent whether loose checks the package manager may have. Just considering your suggestion, the obvious immediate exploit is to not deploy the attack payload right away. Nothing you will think of will evade defeat.
> Nothing you will think of will evade defeat. Trust. Why is it that random people can submit packages? Make it so they can't. Only trustworthy people should be able to do that. People who care, so that we don't have to. People we can trust. This is how Linux distributions work and you just don't see malware randomly making its way into official repositories.
E.g. "This is maintained by a huge network of contributors who contribute to other huge projects" vs "This is a single developer with a couple commits a year"
Earlier quoted context omitted.
I wish it worked that way. I just peeked into how python packages in debian-based distros work. They are most frequently PyPI packages with some debian wrapping, so we're back at the same problem.
PyPI allowed me to make an account and just push packages there like it was nothing. Great for me, not so great for users. These Debian wrappers, however minimal, imply the existence of a maintainer trusted by the Debian community. It's assumed that this maintainer has read the source code and determined it is safe.
Earlier quoted context omitted.
That breaks “npm run” (violating the second part of my request).
The manpage says that directly invoking a script from package.json with `npm run X` aka `npm run-script X` will still work with this preference set to true, but that it will not run pre/post scripts. Perhaps that is good enough for your use-case? npm help run-script [...] ignore-scripts o Default: false o Type: Boolean If true, npm does not run scripts specified in package.json files. Note that commands explicitly in…
And yet again, twice in a row this time. Note how the referenced Virustotal result has 40+ detections [1]. I'm still wondering why info like this isn't used by Pypi and NPM. Chocolatey has Virustotal integration for all releases. And it's not like Virustotal is the only option, there is Cape [2] for dynamic execution, Metadefender, and Intezer Analyze just to name a few. Really confusing for such a vital supply chain…
It’s not clear that this would be useful; at least for the coa package, the DLL was downloaded dynamically via a script, so NPM would not have been able to detect it unless the script itself was flagged. Not sure what Chocolatey does, but it’s also hard to threshold on VirusTotal when there are a lot of FPs by random vendors.
Here's FAR manager which for some reason has some hits on virustotal
Genuinely curious: why is malware always discovered in npm packages, and not pip (python), gradle/maven (JVM), cabal (Haskell), cargo (Rust), CRAN (R), etc.? Or are there major vulnerable packages in those repos but they just don't get audited?
Part of the NPM issue is that everything gets atomized into tiny libraries and no one seems to care about the dependency explosion.