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

Malicious npm packages detected across Red Hat Cloud Services

github.com

Post reply on HN
Print view View original

201–210 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#201

Post by _flux »

phoronixrly wrote: post #55
blm126 wrote: post #33

Earlier quoted context omitted.

The one week cooldown option is not relying on other users to be a canary for you. Its just giving automated scanners a chance to notice. This is the perfect example. I don't think step security found this by accident. They are actively monitoring NPM package releases at some level. There is something to be said that Microsoft should be scanning packages pre-release. They aren't, though, so for right now there is a t…

Thank you for the thorough response. I got the following from yours and other responses: * The JS ecosystem has been and will most likely continue to be fast-moving, so it's quite a safe assumption that at no point will a quarantine period be wide-spread. * This quarantine period is for (semi-)automated scanners to catch the issue. Although considering the above there will always be a non-zero amount of end-user cana…

> Maybe NPM should run scanners before distributing malware?

I suspect there's always a human checking these results. If NPM straight out rejects an update due to suspected malware, they might end up rejecting correct updates as well. If they grant some "safe" patterns a special pass, they might get exploited.

So I think this only works if you have security scanners that are well-maintained and kept in secret. NPM folks could of course co-operate with some security companies to have a first stab with the releases before they are put to public access. At some point some parties might start want to have monetary compensation for such an arragnement, though.

Re: Malicious npm packages detected across Red Hat Cloud Services

#202

Post by orphea »

homebrewer wrote: post #133
bob1029 wrote: post #69

Earlier quoted context omitted.

Furthering the idea that not all package managers are the same, there are entire cycles of the moon where I don't open nuget once. Some ecosystems simply don't need to vendor out very often, and these are the ones where you generally find the least news like this. In about 99% of cases, I have the option to pick between Microsoft, a 3rd party or myself. I'm picking that first option every time I can. If M$ can't hand…

How large a project do you typically use dotnet for? IME dotnet dependency situation is a tire fire, not a month goes by without another dependency biting the dust or going fully commercial with no notice. Which is fair, I suppose, but Go and Java ecosystems don't have it nearly as bad.

I don't think going commercial has been that impactful. It sucks, it betrays the spirit of open source but whatever. A few examples:

- FluentAssertions had no moat, and it has been forked as AwesomeAssertions. Not sure what the author's play was here.

- Moq lost trust - we have NSubstitute

- AutoMapper and MediatR have been widely misused anyway

- Maybe MassTransit is a real bummer?

Re: Malicious npm packages detected across Red Hat Cloud Services

#203

Post by paulddraper »

gbuk2013 wrote: post #17

I came across this interesting rant the other day: https://github.com/uNetworking/uWebSockets.js/blob/master/mi... It does make sense that the right way would be to fork every dependency you use and install from your own repo reviewing and merging from upstream as needed. Would be a giant PITA though. :)

The problem is the volume of dependencies. Most modern JavaScript, Python, Rust, Go, etc. projects have many dozens of transitive dependencies.

Re: Malicious npm packages detected across Red Hat Cloud Services

#204

Post by rixed »

Someone1234 wrote: post #34
jofzar wrote: post #3

'No Way to Prevent This,' Says Only package manager Where This Regularly Happens Edit: some people don't understand that it's a defence to https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...

Let me provide context, since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes. That's an INSANE default. pnpm, by contrast, allows you to essentially "opt-in" only specific packages that need this (e.g. four out of thirty, in one of our projects). Then tacks on tons of oth…

One hour ago, while looking casually at a package.json, I saw this and was horrified:

  rm -rf pkg/snippets & rmdir pkg\\snippets /s /q & wasm-pack build --target bundler && node prepare-web.js
Looked like a strange mix of unix shell and msdos batch that would, on my box, try to rmdir "/s" and "/q". I asked Claude about this, and he replied something like "Yes that's a standard and clever hack to delete a directory that works both on linux and windows!".

Poor Claude has been trained on so much awful human code that it required several prompts for it to admit that there was indeed a problem.

The industry is the process by which convenient crap like this gets standardized.

Re: Malicious npm packages detected across Red Hat Cloud Services

#206

Post by oblio »

johannes1234321 wrote: post #107
bob1029 wrote: post #69

Earlier quoted context omitted.

Furthering the idea that not all package managers are the same, there are entire cycles of the moon where I don't open nuget once. Some ecosystems simply don't need to vendor out very often, and these are the ones where you generally find the least news like this. In about 99% of cases, I have the option to pick between Microsoft, a 3rd party or myself. I'm picking that first option every time I can. If M$ can't hand…

> Furthering the idea that not all package managers are the same, there are entire cycles of the moon where I don't open nuget once. Some ecosystems simply don't need to vendor out very often, and these are the ones where you generally find the least news like this. This however is only to some degree the package manager's fault. The JavaScript culture is strongly ordering tiny packages by individual people doing sma…

> That small package mentality a trace to web usage: JavaScript code is often sent to the client, not having a huge library but having small dedicated libraries means that it is a lot simpler for the bundler to not bundle dead code which is sent to the browser client.

Which is another part of this entire insanity:

Browsers are already >. They're also built by > companies companies that collect > of analytics.

You'd think at this point they could present a proposal for a rock solid extended JavaScript standard library that would be based on actual website usage and would be comparable to what Java, .NET offer, obviously only keeping the parts that would be applicable to the web.

It sounds crazy but I think the Chrome installer is 150MB and an entire decent stdlib these days would probably be 1-5MB...

Re: Malicious npm packages detected across Red Hat Cloud Services

#207

Post by kylebebak »

dmix wrote: post #5

Our company uses yarn 4 which has an option to prevent you from installing an npm package for the first number of days of its release. Most of these seem to be caught within that timeframe (1-3 days). https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...

npm supports this now as well, with e.g. `min-release-age=7` in `.npmrc`

Re: Malicious npm packages detected across Red Hat Cloud Services

#208

Post by Pxtl »

The combined features that make npm particularly vulnerable:

1) Update by default. Manually updating your package references is annoying and does lead to other security issues as you don't automatically get latest, but it makes this risk much lower.

2) Code executed on install. Statically-typed languages don't run the code until you use them, and that might not happen on the developer machine at all for first run after upgrade, it might be a lower-priv test-server.

3) Culture of many tiny modules (this is good! It's the natural way to fight NIH! Yay modularity!) means many more points-of-failure for security for this kind of attack.

Re: Malicious npm packages detected across Red Hat Cloud Services

#209

Post by oblio »

IshKebab wrote: post #171
an0malous wrote: post #145

Earlier quoted context omitted.

What other package managers do this? I don’t think Ruby does

Python does too I believe. Really the reason not to allow that is for robustness, not security. You ideally don't want package installs doing random stuff to your system because package authors are generally bad at doing that sort of thing cleanly. The security impact is relatively minimal because as other people have said, you just installed a package. What's the very next thing you're going to do? Compile/run it ob…

A lot of packages are pulled in to call minimal bits of the actual library. I obviously don't have any statistics on this but my instinct would say that for the average application only 5% of an average package is actually used.

So not running package installation scripts is a huge, massive problem.

Post reply on HN