Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Embedded malware in RC (NPM package)

github.com

Post reply on HN
Print view View original

101–110 of 117 posts

Re: Embedded malware in RC (NPM package)

#101

Post by rndhouse »

throwaway984393 wrote: post #81
rndhouse wrote: post #77

Earlier quoted context omitted.

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.

So every version of every dependency of every package needs a review? It only takes one version of one dependency of any software package to be compromised by supply chain.

Each developer may choose to minimize the software dependency attack surface to a different degree.

Perhaps they would trust a package published by Google without a review. But would require a review before using a package from an indie developer.

Incremental decreses in the attck surface are valuable.

Re: Embedded malware in RC (NPM package)

#102

Post by SpaceManiac »

jiggawatts wrote: post #94
bluefox wrote: post #57

Is the advisory genuine? It links to the github repo, where the latest commit is from 2018 for version 1.2.8. It links to npmjs page, that shows 48 versions, where the latest version is 1.2.8 from "3 years ago". Yet it has 1.2.9/1.3.9/2.3.9 for "Affected versions". Did npmjs "revert" these versions and any clue of their existence? The npmjs page links to dominictarr's repository. The npmjs site doesn't seem to have a…

Practically all package managers (NuGet, crates.io, NPM, etc...) are decoupled from the source code. What you download is NOT necessarily what's in GitHub. I pointed this flaw out repeatedly in the Rust forums when there were discussions related to improvements that could be to crates.io. They made it very clear that "everyone understands" that crates themselves are the "source of truth", and that nobody should be do…

I think I remember discussing this briefly in #rust with you. It's clearly not the case that "everyone understands" how these package managers actually work, but I'd rather see the reality become more obvious than give up and shackle these package ecosystems to Microsoft even harder than they already are.

Re: Embedded malware in RC (NPM package)

#104

Post by bqkJoKocJz9jz »

bluefox wrote: post #60
hjek wrote: post #2

More info: https://therecord.media/malware-found-in-coa-and-rc-two-npm-...

Thanks. > Since then, the npm security team has removed all the compromised coa and rc versions to prevent developers from accidentally infecting themselves. Removing all trace of evidence is not something "security teams" should do. Instead of sweeping security incidents under the rug (where twitterverse resides), they should at least mention the existence of these versions and that they contain malware on the packa…

They posted the [version diffs] (https://my.diffend.io/npm/coa/2.0.2/2.0.4)in the article. Not sure if this site catches all the changes though.

Re: Embedded malware in RC (NPM package)

#105

Post by qPM9l3XJrF »

schemescape wrote: post #21
iancarroll wrote: post #8

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.

Why would malware authors target NPM in particular? Maybe they are targeting lots of package registries, and NPM is just more vigilant?

Re: Embedded malware in RC (NPM package)

#106

Post by tommek4077 »

armchairhacker wrote: post #87

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?

The older such a system is, the more there is a "don't trust anyone" mentality. Some decades in the past you did not just run alien code in your system.

Edit: without looking at it beforehand

Re: Embedded malware in RC (NPM package)

#107

Post by moreati »

armchairhacker wrote: post #87

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?

It isn't always just in NPM, although NPM might be more targetted and/or more publicised.

There have been cases in PyPI (e.g. https://labs.sogeti.com/analysis-of-the-biggest-python-suppl..., https://thehackernews.com/2021/08/pypi-python-package-reposi...), and probably others too, but PyPI is the one I care about.

Re: Embedded malware in RC (NPM package)

#108

Post by greggman3 »

Would it be better for package managers to default to staying at a fixed version? I know npm defaults to semver upgrades. You say

    npm install foo@3.1.7
And it, by default, inserts "foo@^3.1.7" which means "anything 3.1.7 or higher but not "4.x.x".

In other words, the next time someone installs the dependencies it could be 3.1.8, 3.9.7, 3.1234.999 etc...

But maybe it should default to just the actual version and all upgrades should be required to be manual. Checking my HD I see I have lots of references to "rc@^1.1.6", "rc@^1.2.8" etc, all of which would install 1.2.9 if reinstall the deps

Re: Embedded malware in RC (NPM package)

#109

Post by schleck8 »

armchairhacker wrote: post #87

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?

There definitely is malware around on PyPI, and typosquatting.

Re: Embedded malware in RC (NPM package)

#110

Post by jiggawatts »

SpaceManiac wrote: post #102
jiggawatts wrote: post #94

Earlier quoted context omitted.

Practically all package managers (NuGet, crates.io, NPM, etc...) are decoupled from the source code. What you download is NOT necessarily what's in GitHub. I pointed this flaw out repeatedly in the Rust forums when there were discussions related to improvements that could be to crates.io. They made it very clear that "everyone understands" that crates themselves are the "source of truth", and that nobody should be do…

I think I remember discussing this briefly in #rust with you. It's clearly not the case that "everyone understands" how these package managers actually work, but I'd rather see the reality become more obvious than give up and shackle these package ecosystems to Microsoft even harder than they already are.

NPM, Cargo, and the like are basically like the people saving a link to a random Wikipedia article, and then making the shocked Pikachu face when their presentation in front of the boss shows a defaced article with the Goatse picture in the middle of it.

There's a solution to this problem, of course. The Wikipedia team provides the tools you need! You can link to a specific revision of an article so there are no surprises. What you saw when you reviewed the content is what you get when you project it in the board room, or send out that mass email that includes your boss.

Similarly the solution for crates.io could be as simple as having hyperlinks go only to specific commit hashes. And then require that the crate content match the hash.

These days I hear a lot of developers complain that they "Just want to...". I always complete the sentence with "... ignore my responsibilities."

Package managers are in the same camp. "I just want to distribute packages.". Okay, sure, but your responsibility is to do it so that downstream consumers fall into the pit of success and aren't burned by supply-chain attacks.

You can argue, or you can start working on catching up to the encyclopedia people that came from a background in porn hosting and start taking security seriously.

Post reply on HN