←back to thread

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

(socket.dev)
1208 points jamesberthoty | 1 comments | 16 Sep 25 11:22 UTC | HN request time: 0.479s | source
Show context
ants_everywhere ◴[16 Sep 25 12:09 UTC] No.45261149[source]▶
This seems like something that can be solved with reproducible builds and ensuring you only deploy from a CI system that verifies along the way.

In fact this blog post appears to be advertising for a system that secures build pipelines.

Google has written up some about their internal approach here: https://cloud.google.com/docs/security/binary-authorization-...

replies(1): >>45266636 #
herpdyderp ◴[16 Sep 25 19:17 UTC] No.45266636[source]▶
With repos and workflows being infected, wouldn't a CI-only deploy not help?
replies(1): >>45267470 #
ants_everywhere ◴[16 Sep 25 20:23 UTC] No.45267470[source]▶
The malware is modifying files and adding github workflows. If your builds are reproducible and run from committed code then the only way to add the post install script is if the maintainer reviews and accepts the commit that adds it. Similarly with the github workflow branch.

And if your CI is building and releasing in a sandboxed hermetic environment, then the sandboxes that build and release don't need credentials like AWS_ACCESS_KEY because they can't depend on data from the network. You need credentials for deploying and signing, but they don't need to be present during build time.

replies(1): >>45267689 #
herpdyderp ◴[16 Sep 25 20:37 UTC] No.45267689[source]▶
> The malware is modifying files and adding github workflows. If your builds are reproducible and run from committed code

Exactly: it can simply commit its code and trigger a CI-only GitHub Actions deploy with no input from the maintainer at all.

replies(1): >>45267857 #
1. ants_everywhere ◴[16 Sep 25 20:50 UTC] No.45267857[source]▶
Not from a the malicious branch.

By hypothesis the code only deploys from code committed to the main branch (or whatever the blessed branch for CI is). To create a GitHub Action that can deploy the code, the package maintainer must first manually approve and merge the malicious commit.

And the malware spreads by publishing new versions of NPM packages using credentials on the package owner's development machine. If the package owner didn't have credentials with publish access, this wouldn't spread like a worm. And if they had reproducible builds they wouldn't pull a new version of their dependencies from NPM at build time because they'd have to have pinned specific versions with specific hashes to get reproducibility.

Under these hypotheses it can spread, but only if the package owner manually pins a malicious version or manually approves a malicious commit.