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

91–100 of 117 posts

Re: Embedded malware in RC (NPM package)

#91

Post by chakkepolja »

Groxx wrote: post #66
megumax wrote: post #18

Earlier quoted context omitted.

Ok, now, what languages beside Python and Go provide Command line argument parsing? And Go doesn't do that in a `professional` way. You either write your own, which can easily turn into a clusterfuck or use a third party library. Even in Go, people use cobra[1]. Also embedding a lot of functionality in a standard library isn't great as well, because if some vulnerability is found, it's really hard to patch it, becaus…

as if there even was one command-line or config standard. especially across different operating systems. it absolutely does not belong in stdlibs, where it can never be changed. that's how you end up with too many terrible CLI tools using Go's `flags` package.

I don't understand, what's wrong with Go's flag, compared to, say, python's argparse?

Re: Embedded malware in RC (NPM package)

#92

Post by binarynate »

cxr wrote: post #78
binarynate wrote: post #47

This is why JS runtimes should add the ability to set permissions on a per-module basis. Deno is a step in the right direction by requiring permissions for a script to be specified (e.g. deno run --allow-read --allow-net myscript.ts), but the permissions are global for the entire script and can't (yet?) be configured differently for each module / dependency.

Alternatively, JS programmers should exhibit less contempt for the standardized, sandboxed runtime that JS was originally created to target: the Web browser. What's nuts is that any of these projects (whether they be single components, larger utilities, or full-blown apps) require a build step that involves anything more complicated[1] than a single machine-readable document in the web browser's native file format an…

JS programmers don't have contempt for browsers, it's just that server runtimes like Node and Deno serve a different purpose. A browser isn't the right tool for running a server application or a command line program. If you want a server runtime that behaves more like a browser, though, check out Deno.

Re: Embedded malware in RC (NPM package)

#93

Post by [deleted] »

speeder wrote: post #63
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…

I saw in one of the repos the maintainer confused about what happened, seemly someone somehow impersonated him and released new versions to npm without actually touching the repo itself!

[deleted]

Re: Embedded malware in RC (NPM package)

#94

Post by jiggawatts »

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 doing security reviews by going to GitHub or wherever.

So what happens in reality?

Precisely what you just did. People instinctively click the source repo link, and browse around in the GitHub history view to "see what happened".

Sigh.

It's like trying to explain to someone that the cargo lift design of the Death Star is dangerous without handrails. Then someone points out that when you signed up to be a Stormtrooper on the Death Star there was a clause in the contract (page 537 paragraph 7) that clearly states that it is your responsibility to avoid fatal falls due to precipitous ledges.

Re: Embedded malware in RC (NPM package)

#95

Post by forty »

tolmasky wrote: post #51
forty wrote: post #32

Earlier quoted context omitted.

Isn't that only useful for the very rare minority of people that install packages then don't run the code right after? :)

The fact that they don't need to be run is what makes them so hard to spot and easy to sneak in. This allows for some very hard to mitigate strategies. It's easier to sneak in packages into metadata files like package.jsons than create "excuses" to import files that aren't really needed. It can be abused in more complicated ways as well, like for example: 1. You add a totally "safe" dependency that you control, let's…

I understand the attack but my point is that the next step after installing the popular package is probably to import/require it in my code, then run my unit tests, which will allow the evil package to run whatever code they intended to run.

Re: Embedded malware in RC (NPM package)

#96

Post by forty »

Me1000 wrote: post #55
forty wrote: post #32

Earlier quoted context omitted.

Isn't that only useful for the very rare minority of people that install packages then don't run the code right after? :)

Many packages on npm are not run in a local node environment, they run in a browser which is sandboxed. Regardless, just because there are additional vectors to exploit the user doesn't mean closing off one vector isn't worth doing.

Yeah I also thought of that but aren't front end devs running some kind of unit test in node? Do they always run everything in their browser? (Honest question, I'm a BE person)

Re: Embedded malware in RC (NPM package)

#97

Post by cxr »

binarynate wrote: post #92
cxr wrote: post #78

Earlier quoted context omitted.

Alternatively, JS programmers should exhibit less contempt for the standardized, sandboxed runtime that JS was originally created to target: the Web browser. What's nuts is that any of these projects (whether they be single components, larger utilities, or full-blown apps) require a build step that involves anything more complicated[1] than a single machine-readable document in the web browser's native file format an…

JS programmers don't have contempt for browsers, it's just that server runtimes like Node and Deno serve a different purpose. A browser isn't the right tool for running a server application or a command line program. If you want a server runtime that behaves more like a browser, though, check out Deno.

The runtime environment of the application itself is a separate matter from the environment needed during the fetch-and-configure phase for the modules that the application depends on.

This malware was lurking in an auto-executing script that runs upon merely trying to fetch the module. Under the regime that I outlined, malicious actors would be forced to try doing their dirty work within the module's business logic itself, which is far easier to mitigate—for example, with a policy where no code gets merged into the application without undergoing review, whether it is written by a third-party or someone on your team. In spite of all the craziness that the 2010s led to with the rise of specialized package registries trying to recreate CPAN (often erroneously called "language package managers") and giving the illusion that there is such a thing as a free lunch, we're going to have to eventually deal with reality and accept that this is the only reasonable way to approach software development for the stuff that we need to rely on (and that no amount of trying to sweep the problem under the rug with references to Trusting Trust will make the counterargument a sound one).

Re: Embedded malware in RC (NPM package)

#98

Post by cookiengineer »

Every time I see news like this, I am amazed by the absolute lack of permission management in nodejs and npm.

I mean, a package.json with changing permissions and an alert or manual confirmation step could've easily fixed this.

NPM is pretty much the definition of a security nightmare, because you cannot guarantee anything.

Any dependency down the tree can compromise anything upstream.

I think that package managers must offer build bots that use the source codes (git repositories) as sources of truth rather than their own packages. That's the only way that comes to mind to guarantee that the publisher of the package is actually the same owner.

If a git repo changes, warn all users. If a permission changes, warn all users. If a header/symbol file changes, warn all users.

Re: Embedded malware in RC (NPM package)

#99

Post by tmpfs »

nijave wrote: post #84
schemescape wrote: post #21

Earlier quoted context omitted.

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.

I've seen some talks about implementing this at the programming level but can't remember the specifics. Basically treating dependencies similar to apps on a smartphone where they each run in a namespace or security context and there's control over what data gets passed in and out of the module or package. (In stark contrast to the current model where everything just runs in a global namespace)

We are working on this here [1].

Uses the object capability model provided by SES [2].

[1] https://github.com/LavaMoat/LavaMoat [2] https://github.com/endojs/endo

Re: Embedded malware in RC (NPM package)

#100

Post by Angius »

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's an attractive target. Other ecosystems (maybe besides Rust) rely on large packages with minimal dependencies, and those packages are often first-party (Entity Framework, for example).

NPM meanwhile is a neverending net of tiny oneliner packages, required by other oneliner packages, required by twoliner packages, required by single-function packages, required by... required by React. And thus, adding malware to `is-number` adds it to all 8766235452 packages that depend on it.

Post reply on HN