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

Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

safedep.io

Post reply on HN
Print view View original

291–300 of 329 posts

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#291

Post by sscaryterry »

skydhash wrote: post #279
joshkel wrote: post #250

Earlier quoted context omitted.

> But nowadays prefer pyproject.toml, and most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages. Yes, and these are positive changes. But they aren't security boundaries, and they don't mean that pip won't execute arbitrary code: a malicious update could ship an update with sdist instead of wheels, a malicious pyproject.toml could provid…

> Early JS had a relatively anemic standard library in the early days, and NPM made code reuse dramatically simpler than before. This normalized the use of large and deep dependency trees among JS projects. This always seems like a very convenient excuse. C also have a very small standard library. And unless you're doing system programming, you often have to find utility library. It's just that those libraries tries…

The whole JS ecosystem is insane. ESM, CJS, are still, and will be issues for the next 5-10 years.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#292

Post by Rohansi »

notnullorvoid wrote: post #239
Rohansi wrote: post #144

Earlier quoted context omitted.

If postinstall scripts are restricted the people behind these attacks will switch to something else. Package code is executed automatically by Node when imported, which could be a good replacement. It'll probably run when tests run instead but it's still going to run for most people.

Limiting post install as an attack vector is still a good thing. Node is working on a similar permission model to Deno that allows explicitly granting certain system resource permissions https://nodejs.org/api/permissions.html . Using it should help reduce impact from malicious code, though if you allow wide permissions it's unlikely to help.

> Limiting post install as an attack vector is still a good thing.

If npm got rid of the post install scripts it would permanently break the install process of packages that use it. Affected systems will need to bypass it, stay on an old npm version, or upgrade the packages to versions that work without post install. Meanwhile, attackers switch to a different attack vector and continue.

Who does that help?

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#293

Post by Icathian »

ErroneousBosh wrote: post #195
Icathian wrote: post #136

Earlier quoted context omitted.

Yeah, I'm reminded of 15 years ago being told Linux was super secure because people were popping Windows all the time. Turns out it was mostly just a function of effort pointed at the target, and I don't have any reason to believe that's not the case here too.

Linux has had 100% market penetration for 20 years or so now. Everyone using a computer uses Linux *somewhere* in it. You'd think if it was that easy, there would be exploits all over the place. Why isn't every single desk phone and router part of a botnet?

Kimwoolf and Aisuru kind of make my point better than yours, I think?

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#294

Post by equinumerous »

megous wrote: post #286
gus_ wrote: post #118

Earlier quoted context omitted.

Personally I don't allow outbound connections from almost any app, except web browsers to port 80/443. So nodejs, pip, ruby, curl, wget, etc, opening unexpected outbound connections is a big red flag for me. In some cases, maybe you need to allow permanently git to open outbound resquests to github.com (or gitlab, etc), but at least in my case, I'm okey allowing these connections manually. > preinstall script: bun ru…

1) write a well crafted exfil payload to mozilla or chrome directory (there are sqlite databases and files that store eg. indexeddb content) 2) trigger a tab open to attacker's website, website takes the exfil data from indexeddb and posts it to the server (have something inocuous looking on that website - like a fake npm homepage or whatever, so you don't close it fast enough) from one step process, this will become…

This is genius. Let's hope the hackers aren't reading this...

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#295

Post by thrownthatway »

sitkack wrote: post #287
thrownthatway wrote: post #190

Earlier quoted context omitted.

Are you ok? Compared to calling in air support on cyber criminals. How’s your reading comprehension coming along?

wtf does shop lifting have to do with the conversation and why would it take priority vs anything else ? how is that an argument don't attack people like this on this forum or you will get banned

We can’t even prevent shoplifting, what expectation should there be that we’d be capable of mounting any sort of offence / defence against malware outfits.

I dunno, some people just have no sense of humour.

> or you will get banned

Oh yeah, run and tell the teacher. Dibberdobber.

Tell me, did you grow up in a fatherless home?

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#297

Post by no-name-here »

rubnogueira wrote: post #40

aube (npm/yarn/pnpm drop-in alternative) now has a "jailBuilds" flag that restricts access to network/filesystem access. https://aube.en.dev/package-manager/jailed-builds.html But this feels like a cat/mouse game.

> aube (npm/yarn/pnpm drop-in alternative) now has a "jailBuilds" flag that restricts access to network/filesystem access.

1. It seems like the restrictions are only for lifecycle scripts, so wouldn't help if/when the package's actual code had malicious code inserted?

2. Package managers like pnpm seem to entirely block lifecycle scripts by default, so I guess this is an in-between solution.

Still, I guess it's a step in the right direction for those want or need to run lifecycle scripts specifically.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#298

Post by freakynit »

HDBaseT wrote: post #296
freakynit wrote: post #212

Collected all the attacks that happened in the npm ecosystem in past 1 year here: https://npm-supply-chain-attacks-25-26.pagey.site/

Did Claude generate this site? The scroll seems to jump all over the place on my device.

yep... fixed it in new version. Thanks for mentioning.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#299

Post by jcgl »

megous wrote: post #286
gus_ wrote: post #118

Earlier quoted context omitted.

Personally I don't allow outbound connections from almost any app, except web browsers to port 80/443. So nodejs, pip, ruby, curl, wget, etc, opening unexpected outbound connections is a big red flag for me. In some cases, maybe you need to allow permanently git to open outbound resquests to github.com (or gitlab, etc), but at least in my case, I'm okey allowing these connections manually. > preinstall script: bun ru…

1) write a well crafted exfil payload to mozilla or chrome directory (there are sqlite databases and files that store eg. indexeddb content) 2) trigger a tab open to attacker's website, website takes the exfil data from indexeddb and posts it to the server (have something inocuous looking on that website - like a fake npm homepage or whatever, so you don't close it fast enough) from one step process, this will become…

Damn, good call. Really reinforces the need for sandboxing.

Still doesn’t negate the value of OpenSwitch, since the majority of malware won’t do that. But really good to keep in mind.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#300

Post by freakynit »

kjok wrote: post #216
freakynit wrote: post #212

Collected all the attacks that happened in the npm ecosystem in past 1 year here: https://npm-supply-chain-attacks-25-26.pagey.site/

Please also collect responses from people, you'd find a pattern: a new attack is launched, people make noise, and later go back to installing packages the same way. Enterprises already use private registries to combat such attacks, vulnerable folks include individual devs and small teams.

Want to.. but I'll need to first integrate social-media and forum scanning in my tool. Haven't done that yet.

But, it's a good feature to have.

Thanks.. gonna integrate now :)

Post reply on HN