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

Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

socket.dev

Post reply on HN
Print view View original

921–930 of 1001 posts

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#921

Post by jcgl »

jcgl wrote: post #862
l___l wrote: post #10

Is there a theoretical framework that can prevent this from happening? Proof-carrying code?

I think I’m gonna start wrapping most of my build commands (which are inside a makefile) with bwrap. Allow network access only for fetching dependencies. Limit disk access (especially rw access) throughout. Etc.

If anyone is interested, I've added this BWRAP_BUILD variable to a makefile in my project that builds a Go and SvelteKit project. I then preface individual commands that I want sandboxed within a make target (e.g. mybin below).

  PATH_ELEMENTS := $(subst :, ,$(PATH))
  BIND_COMMANDS := $(foreach element, $(PATH_ELEMENTS), --ro-bind-try $(element) $(element))
  
  define BWRAP_BUILD
  bwrap \
  --unshare-all \
  --unshare-user \
  --die-with-parent \
  --disable-userns \
  --ro-bind /usr/ /usr \
  --ro-bind /lib64 /lib64/ \
  --ro-bind /lib /lib \
  --ro-bind /etc/alternatives/ /etc/alternatives/ \
  --ro-bind $(CURDIR) $(CURDIR) \
  --proc /proc \
  --clearenv \
  --setenv PATH $(PATH) \
  $(BIND_COMMANDS) \
  --setenv GOPATH $(GOPATH) \
  --ro-bind $(GOPATH) $(GOPATH)  \
  --setenv TMPDIR $(XDG_CACHE_HOME)/go-build  \
  --bind $(XDG_CACHE_HOME)/go-build $(XDG_CACHE_HOME)/go-build  \
  --setenv XDG_CACHE_HOME $(XDG_CACHE_HOME)  \
  --dev-bind /dev/null /dev/null  \
  --setenv PNPM_HOME $(PNPM_HOME) \
  --bind-try $(PNPM_HOME) $(PNPM_HOME) \
  --setenv HOME $(HOME) \
  --bind-try $(CURDIR)/ui/.svelte-kit $(CURDIR)/ui/.svelte-kit \
  --bind-try $(CURDIR)/ui/build $(CURDIR)/ui/build \
  
  endef
  
  mybin: $(deps)
    $(BWRAP_BUILD) go build -trimpath -ldflags $(ldflags) ./cmd/mybin/
Notes: most of the lines after --setenv GOPATH... are specific to my project and tooling. Some of the lines prior are specifically to accommodate my tooling, but I think that stuff should be reasonably general. Lmk if anyone has any suggestions.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#922

Post by VPenkov »

theodorejb wrote: post #876
VPenkov wrote: post #833

Earlier quoted context omitted.

It does not, since version 11: https://docs.npmjs.com/cli/v11/using-npm/changelog#1100-pre0...

Yes it does, since the ignore-scripts option is not enabled by default.

Yes it does, you're correct and I have misread. I can't edit, delete, or flag my initial reply unfortunately.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#923

Post by 999900000999 »

silverliver wrote: post #871
999900000999 wrote: post #866

Earlier quoted context omitted.

The "solution" would be using a language with a strong standard library and then having a trusted 3rd party manually audit any approved packages. THEN use artifactory on top of that. That's boring and slow though. Whatever I want my packages and I want them now. Apart of the issue is the whole industry is built upon goodwill and hope. Some 19 year old hacked together a new front end framework last week, better use it…

This is the right answer. I'm willing to stick my head out and assert that languages with a "minimal" standard library are defective by design. The argument of APIs being stuck is mood with approaches like Rust's epocs or "strict mode". Standard libraries should include everything needed to interact with modern systems. This means HTTP parsing, HTTP requests, and JSON parsing. Some laguages are excellent (like python…

It's not an easy problem to solve.

Doing it the right way would create friction, developers might need to actually understand what the code is doing rather than pulling in random libraries.

Try explaining to your CTO that development will slow down to verify the entire dependency chain.

I'm more thinking C# or Java. If Microsoft or Oracle is providing a library you can hope it's safe.

You *could* have a development ecosystem called Safe C# which only comes with vetted libraries and doesn't allow anything else.

I'm sure other solutions already exist though.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#925

Post by Natfan »

JoBrad wrote: post #905
Arcterus wrote: post #891

Earlier quoted context omitted.

> Standard libraries should include everything needed to interact with modern systems. This is great when the stdlib is well-designed and kept current when new standards and so on become available, but often "batteries included" approaches fail to cover all needs adequately, are slow to adopt new standards or introduce poorly designed modules that then cannot be easily changed, and/or fail to keep up-to-date with the…

The tradeoff of “batteries included” vs not is real: Python developers famously reach for community libraries like requests right away to avoid using the built-in tooling.

I wasn't even aware there _was_ built-in tooling...

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#927

Post by johnisgood »

cesarb wrote: post #573
worik wrote: post #513

Earlier quoted context omitted.

What is a "typical Rust project", I wonder?

One famous example is ripgrep ( https://github.com/BurntSushi/ripgrep ). Its Cargo.lock (which contains all direct and indirect dependencies) lists 65 dependencies (it has 66 entries, but one of them is for itself).

Not quite. He is a better developer than most who happen to minimize dependencies, but according to my experiences it is not as common as you would like to believe. Do I really need to make a list of all the Rust projects I have compiled that pulled in over 1000 dependencies? If I need to do it to convince you, I will do so, as my time allows.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#928

Post by johnisgood »

burntsushi wrote: post #605
cesarb wrote: post #573

Earlier quoted context omitted.

One famous example is ripgrep ( https://github.com/BurntSushi/ripgrep ). Its Cargo.lock (which contains all direct and indirect dependencies) lists 65 dependencies (it has 66 entries, but one of them is for itself).

Also, that lock file includes development dependencies and dependencies for opt-in features like PCRE2. A normal `cargo build` will use quite a bit fewer than 65 dependencies. I would actually say ripgrep is not especially typical here. I put a lot of energy into keeping my dependency tree slim. Many Rust applications have hundreds of dependencies. We aren't quite at thousands of dependencies yet though.

> I would actually say ripgrep is not especially typical here. I put a lot of energy into keeping my dependency tree slim. Many Rust applications have hundreds of dependencies.

Thank you for your honesty, and like you and I said, you put a lot of energy into keeping the dependency tree slim. This is not as common as one would like to believe.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#929

Post by kernc »

aorth wrote: post #759

In the story about the Nx compromise a few weeks ago someone posted a neat script that uses bubblewrap on Linux to run tools like npm more safely by confining their filesystem access. https://news.ycombinator.com/item?id=45034496 I modified the script slightly based on some of the comments in the thread and my own usage patterns: #!/usr/bin/env bash # # See: https://news.ycombinator.com/item?id=45034496 bin=$(basenam…

Is exactly why I composed bubblewrap-based sandbox-venv for Python: https://github.com/kernc/sandbox-venv

Dangerous times we live in.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#930

Post by rpodraza »

PeterStuer wrote: post #804
kelnos wrote: post #405

As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embed…

Not you. But one would expect major cybersecurity vendors such as Crowdstrike to screen their dependencies, yet they are all over the affected list.

It looks like they actually got infected as well. So it's not only that, their security practices seem crap
Post reply on HN