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

261–270 of 329 posts

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

#261

Post by lovich »

Sohcahtoa82 wrote: post #252
btown wrote: post #113

At a certain point, is it better to just turn off Dependabot and freeze all NPM packages (minor/patch version and all), rather than continuously update? Particularly for frontend packages, meaningful security fixes seem less likely than supply chain attacks these days. It's a sad state of affairs, for sure - but is there a reason we can't just switch our frontends to static BOMs, and trust that NPM at least gets thei…

> At a certain point, is it better to just turn off Dependabot and freeze all NPM packages (minor/patch version and all), rather than continuously update? But then the compliance team gets annoyed because some CVE with a CVSS score of 3.1 that has a patch available sits unfixed.

The core problem is companies skimping on maintenance.

They don’t want to pay engineers to do the analysis manually, and they don’t want to pay for someone to figure out a better automated system.

Would anyone be surprised at their car having problems if they cheaped out on oil changes?

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

#262

Post by jcgl »

gus_ wrote: post #255
jcgl wrote: post #60

Earlier quoted context omitted.

On my personal machine, I run OpenSnitch. Much better defense against data exfil if you reject outbound connections to unexpected/unwanted hosts.

btw, this analysis of a node linux malware with OpenSnitch and other tools was published on reddit a year ago (a malicious linkedin interview targeting web3/crypto devs that resulted in a system compromise): https://markdownpastebin.com/?id=9c294c75f09349d2977a4ccd250...

Excellent example, thank you. This is the kind of stuff that skeeves me out and is entirely within the model of threats that I want to guard against. Sandboxing + OpenSnitch is good stuff. And, ofc, npm bad.

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

#263

Post by [deleted] »

erikerikson wrote: post #145
wavemode wrote: post #138

Earlier quoted context omitted.

I would imagine it's the opposite. Most dev's machines can't query the prod database, for example, whereas a prod server can.

Nope, they've been targeting credentials so they can deploy whatever they like into prod. They prefer the build machine with it's broader rights than the individual dev boxes.

[deleted]

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

#264

Post by lyu07282 »

grim_io wrote: post #210
lyu07282 wrote: post #157

Earlier quoted context omitted.

No look at the article of this post, it's by SafeDep they are in the same business as Microsoft with their Defender product line. They both publish near identical post mortems with subtle hints at how their product would've defended you against the attack. Why should Microsoft fix the cause instead of selling the cure to each business individually?

Is the complete loss of trust in the platform they want to profit off a better alternative?

It's essential infrastructure there is only one node package manager. I'm not saying it's a good thing, I just describe the systemic reason why it's broken, because that's usually never expressed but its important.

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

#265

Post by urbandw311er »

This list is incomplete - at least one other package (nx-console VS code extension; 2.2M downloads) was compromised yesterday with this worm: if suitably qualified/connected people are reading this, it could be worth following that dependency chain too in case there are more. See here:

https://github.com/nrwl/nx-console/security/advisories/GHSA-...

PS: I posted on HN to try and alert people right after it was compromised but sadly got almost no upvotes :-(

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

#266

Post by zenoprax »

cyphar wrote: post #215
zenoprax wrote: post #83

Earlier quoted context omitted.

> "kernel escape doesn’t land you on a 0 UID" I'm not sure I agree/understand. If you've somehow bypassed AppArmor and cgroup mechanisms then any UID/GID remapping is irrelevant. At this point you're in a position to directly manage memory. What do you mean by "kernel escape"?

> If you've somehow bypassed AppArmor and cgroup mechanisms then any UID/GID remapping is irrelevant. At this point you're in a position to directly manage memory. Not really, user namespaces (despite all of the issues that unprivileged user namespaces have caused) provide an additional layer of protection as lots of privilege checks are either based on kuid/kgid or are userns-aware. These are some of the deepest sec…

Awesome, thanks for the explanation. I didn't know that kuid/kgid existed! That also explains why Proxmox manages the re-mapping in the `LXC.conf` rather than the AppArmor profile. The cascade of AppArmor configs seemed to focus quite a bit on access to `/proc` and `/sys` so I think I mixed that up cgroups with my comments about memory access.

I've been reading up on them (https://www.kernel.org/doc/html/latest/filesystems/idmapping...) seeing some of the notation for user IDs (e.g. `u20000`) reminded me that my Hetzner ZFS storage was accessed using a similar UID format for the username.

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

#267

Post by tedd4u »

btown wrote: post #113

At a certain point, is it better to just turn off Dependabot and freeze all NPM packages (minor/patch version and all), rather than continuously update? Particularly for frontend packages, meaningful security fixes seem less likely than supply chain attacks these days. It's a sad state of affairs, for sure - but is there a reason we can't just switch our frontends to static BOMs, and trust that NPM at least gets thei…

Enforce a “seasoning” period, for example don’t let any pull pull versions newer that 30 days. Perhaps with an exception for versions that address known CVEs.

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

#268

Post by okanat »

Rantenki wrote: post #243
kommunicate wrote: post #225

Earlier quoted context omitted.

npm can execute code after install and most package managers don't do that

/me looks at the `build.rs` file in my Rust's project's `Cargo.toml` and laughs nervously... (For non Rustaceans: "Placing a file named build.rs in the root of a package will cause Cargo to compile that script and execute it just before building the package.")

aaand many Cargo packages do use it, right now. It became an inseparable part of Rust ecosystem. You cannot build any embedded program or something slightly complex (omg Protobufs!) without build.rs. Not just your own program but all of your dependencies' build.rs is also executed.

I get the need for simple ways to make ecosystem inviting to the new developers. However, I think Cargo was completely mis-designed for simplicity only, where a system language like Rust should shine in its ability to control complexity. With the bad initial design, they invented hacky solutions like build.rs which speaks a string-based language to talk with Cargo!

On top of that crates.io is completely ripe for typosquatting and package overtakes. I think the ecosystem should be completely revamped to a Maven-style namespaced repos and it should require strong GPG signatures.

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

#269

Post by LtWorf »

thrownthatway wrote: post #199
LtWorf wrote: post #57

Earlier quoted context omitted.

What they do is already illegal. The problem is finding out who they are and where they live to go and arrest them.

I’m not convinced. My understanding is that the problem is more that calling in the heavy artillery for what amounts to an annoyance, and maybe some financial harm, is generally considered impolite, even among nations that have conflicting worldviews.

You are allowed to have a conflicting world-view than USA as long as you have nukes, or, turns out, control a strait.

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

#270

Post by cyphar »

zenoprax wrote: post #266
cyphar wrote: post #215

Earlier quoted context omitted.

> If you've somehow bypassed AppArmor and cgroup mechanisms then any UID/GID remapping is irrelevant. At this point you're in a position to directly manage memory. Not really, user namespaces (despite all of the issues that unprivileged user namespaces have caused) provide an additional layer of protection as lots of privilege checks are either based on kuid/kgid or are userns-aware. These are some of the deepest sec…

Awesome, thanks for the explanation. I didn't know that kuid/kgid existed! That also explains why Proxmox manages the re-mapping in the `LXC.conf` rather than the AppArmor profile. The cascade of AppArmor configs seemed to focus quite a bit on access to `/proc` and `/sys` so I think I mixed that up cgroups with my comments about memory access. I've been reading up on them ( https://www.kernel.org/doc/html/latest/file…

> The cascade of AppArmor configs seemed to focus quite a bit on access to `/proc` and `/sys` so I think I mixed that up cgroups with my comments about memory access.

Funnily enough that is a good example of how fickle AppArmor's protections are -- if you give containers mount privileges (needed to enable container nesting and most system container usecases) you can bypass most (if not all) AppArmor path rules because you can create alternative mounts that don't match the ones in the rules. With the fsopen(2) and open_tree(2) mount APIs, it's even easier -- AppArmor uses d_path to compute the path for policy purposes but detached mounts for procfs do not have a /proc prefix in their d_path form!

My general impression is SELinux is better as it applies to objects directly, but we've had security issues with it too.

Post reply on HN