>Every package install is checked against the threat feed and it raises an exception if we find something malicious being installed.
So your solution is to reinvent signature based antiviruses, like Norton Antivirus and McAffee?
The problem with these 2000s approaches were that attackers could:
1- Fuzz their payloads so that they are never the same and they don't trigger detection.
2- Offload payload mechanisms so that your monitoring system needs to play cat and mouse. For example, what if the malicious code does wget https://IP/file, will you detect wget commands? Will you scan for whatever looks like a URL? Ok, what if they do "another_package_manager_like_flatpack malicious_package", will your scanner implement all package managers? What if they construct the url? "protocol + "://" + domain + file" surely your global hook thing will notice that is a url and how it is downloaded and inspect those contents as well?
3- The attacker can control the timing and infect every user at the same time, especially if they control the update mechanism of users whose security policy is to keep things patched. Even if the malicious update is not simultaneous, the malicious update can start distribution, and the attack only triggered months later (simultaneously) when enough users have downloaded it (beating latency policies).
The only solution is to do actual work and either write the thing you are trying to offload to the 'open source community, or to actually write it yourself. But of course more work is going to be put into the possibility of a magical easy solution, than on an deteriministic hard solution.
These are not 2000 approaches, these are approaches used today (signature based detection).
The difference is that in 2000s the signatures were written by hand and described static file info, today they're often autogenerated and describe the system behavior, either by looking at one executable, or a whole network of computers. But it is still signature based detection. Since they describe the program behavior, not the program structure, then if the program itself stayed the same (the sequence of system api calls stayed the same), no runtime packing/obfuscation makes a difference to a signature. Unless obfuscation changes the behavior.
Also security is not binary, it's layered. Sometimes we can address an attack vector by using multiple levels. And sometimes it's simply worth checking for low hanging fruits if only to make the attack more expensive. The "cat and mouse" game is always about the cost of attack and cost of defense, if we raise one then we win in this area, unless the other party finds a way of lowering the cost of their side. Or unless they pay an unexpected amount of cost, for example in state sponsored malware.
By the way, some security solutions also have actual parsers for example for PowerShell, so they can actually detect string concatenation that constructs the URL.
(Author here). I don’t really care _how and what you decide to do with it_, the post is about package managers giving users the ability to decide.
Dependency Cooldowns can be implemented with global hooks, git-commit-signing checks can be implemented, LLM-scans can be implemented, someone can run the code in a jail and use the eBPF logs to publish a threat feed.
Modern language packaging is also _source available_, and we have a huge leg up over traditional virus scans - we have the source code almost always. You can do amazing static analysis.
This seems to be primarily a problem with NPM, since it's the only package manager that I know of that allows for package authors to essentially run arbitrary post-install scripts silently package install.
Shai Hulud/Mini Shai Hulud happened because of this obvious glaring hole in the system, they even had the script to download an official copy of Bun to spread itself in case the targeted machine has hardened their security. So, the real question is not what other security features does a package manager need, it should be: why does a package manager have the ability to let package authors run arbitrary scripts silently on other people's computer in the first place?
It doesn't really matter how good your security system is if the front door is left wide open for anyone to walk through.
Every package install is checked against the threat feed and it raises an exception if we find something malicious being installed
Ok big problem is lots of stuff installed for campaigns wasn't flagged in any feed. If maintainer access is taken over you still don't have any feed info, maybe it will be a bit faster to publish so if maintainer finds out.
Everyone is looking at NPM how bad it is or AUR lately. Those are "free for all anything can happen, any kid can publish" repositories and that's what you get.
No one looks at Debian and is saying "well maybe we should do what they do"...
I'm the guy that built the antimiasma discovery and mitigation tool [1] and has seen a lot of the evolved and ever-changing malware samples (17 unique deobfuscated samples with different code branches and adapters/functions/features), so I feel somewhat qualified to respond to this.
The problem of everchanging malware isn't fixable by global policies and global rulesets. Package managers need to change to different workflows in the package
publishing process.
1. Reproducible builds have to be mandatory
2. Deployed packages have no execution or network capability at install time
3. If package artifacts differ from source artifacts, block it temporarily
4. In order to defend against credentials harvesting: Package managers need to have mandatory container or sandbox isolation (mandatory bubblewrap, podman, or whatever isolation that segregates filesystems and networking)
5. In order to defend against github being abused as a C2 infrastructure: Package managers need to have locked behavioral rulesets of packages, "allow filesystem" or "allow networking" is useless, and needs to be per-resource. Additionally, it needs to be a mandatory allowlist-only enforcement. If it's allowed by default, it won't help with the transitive dependencies problem
6. Introduced transitive dependencies need to be locked and signed by the package repository authority.
7. In order to defend against eBPF Rootkit: Sorry, you're just f'cked. The only EDR on the market that defends against this attack surface is literally my own product (that I won't advertise here). Every other available tooling is just too outdated in how it has been developed, and too outdated how it's doing behavioral analytics of malware.
---
My personal take on this:
Pretty much every developer thinks this isn't necessary and is probably gonna downvote me for telling the security perspective here. This is not about what's necessary, this is about what's broken.
Our existing DevOps and DevSecOps culture and the involved incident response/supply chain security/GRC/etc workflows are absolutely broken against these reoccurring supply chain attacks, and the tooling that promised to catch this is also absolutely broken and useless against mutating malware that's co-generated by LLMs.
The only ones actually re-identifying the malware implants as miasma malware samples correctly were the socket.dev folks. Every other supply chain tool vendor was just bragging about a new malware campaign because they weren't up to speed and seemingly didn't know about the initial miasma campaigns (and the prototype campaign targeting RedHat's NPM packages with the gyp bindings).
Microsoft was so useless in its incident response workflow that they tried to mitigate the problem by making VSCode extension installs with a required delay time, not even having understood how the malware implants work, and not even having understood what the actual spread vector was.
It's like Microsoft had to press a red button just for the sake of having done anything, instead of openly communicating and advising to ongoing malware attacks, sharing intelligence and samples; and in consequence leaving every customer of Microsoft in the dark, getting compromised in the process, too.
The solution is called curated package feed. Using private one instead of default public package source, you get a trusted source. All updates should be done by first pulling the new packages to the private feed and only after passing the reviews - update.
A little bit of bureaucracy in form of best security practices helps with supply chain attacks.
15 comments
[ 3.2 ms ] story [ 35.0 ms ] threadSo your solution is to reinvent signature based antiviruses, like Norton Antivirus and McAffee?
The problem with these 2000s approaches were that attackers could:
1- Fuzz their payloads so that they are never the same and they don't trigger detection.
2- Offload payload mechanisms so that your monitoring system needs to play cat and mouse. For example, what if the malicious code does wget https://IP/file, will you detect wget commands? Will you scan for whatever looks like a URL? Ok, what if they do "another_package_manager_like_flatpack malicious_package", will your scanner implement all package managers? What if they construct the url? "protocol + "://" + domain + file" surely your global hook thing will notice that is a url and how it is downloaded and inspect those contents as well?
3- The attacker can control the timing and infect every user at the same time, especially if they control the update mechanism of users whose security policy is to keep things patched. Even if the malicious update is not simultaneous, the malicious update can start distribution, and the attack only triggered months later (simultaneously) when enough users have downloaded it (beating latency policies).
The only solution is to do actual work and either write the thing you are trying to offload to the 'open source community, or to actually write it yourself. But of course more work is going to be put into the possibility of a magical easy solution, than on an deteriministic hard solution.
The difference is that in 2000s the signatures were written by hand and described static file info, today they're often autogenerated and describe the system behavior, either by looking at one executable, or a whole network of computers. But it is still signature based detection. Since they describe the program behavior, not the program structure, then if the program itself stayed the same (the sequence of system api calls stayed the same), no runtime packing/obfuscation makes a difference to a signature. Unless obfuscation changes the behavior.
Also security is not binary, it's layered. Sometimes we can address an attack vector by using multiple levels. And sometimes it's simply worth checking for low hanging fruits if only to make the attack more expensive. The "cat and mouse" game is always about the cost of attack and cost of defense, if we raise one then we win in this area, unless the other party finds a way of lowering the cost of their side. Or unless they pay an unexpected amount of cost, for example in state sponsored malware.
By the way, some security solutions also have actual parsers for example for PowerShell, so they can actually detect string concatenation that constructs the URL.
Dependency Cooldowns can be implemented with global hooks, git-commit-signing checks can be implemented, LLM-scans can be implemented, someone can run the code in a jail and use the eBPF logs to publish a threat feed.
Modern language packaging is also _source available_, and we have a huge leg up over traditional virus scans - we have the source code almost always. You can do amazing static analysis.
Yes, it’s hard work. But package managers are doing it already. Yay and Paru both now support hooks. I’m offering to help for AUR to publish more metadata: https://lists.archlinux.org/archives/list/aur-dev@lists.arch...
Shai Hulud/Mini Shai Hulud happened because of this obvious glaring hole in the system, they even had the script to download an official copy of Bun to spread itself in case the targeted machine has hardened their security. So, the real question is not what other security features does a package manager need, it should be: why does a package manager have the ability to let package authors run arbitrary scripts silently on other people's computer in the first place?
It doesn't really matter how good your security system is if the front door is left wide open for anyone to walk through.
TFA is also a bit hazy on what hooks exactly?
Everyone is looking at NPM how bad it is or AUR lately. Those are "free for all anything can happen, any kid can publish" repositories and that's what you get.
No one looks at Debian and is saying "well maybe we should do what they do"...
You don't need your package manager to invoke your hook. You need _your_ tooling to invoke your hook.
./safely-bump-deps.sh && npm install
Want it global? Use a bash alias.
2. This is clearly unacceptable, so we've created the one standard to unite them all™.
3. There are 6 competing standards.
The problem of everchanging malware isn't fixable by global policies and global rulesets. Package managers need to change to different workflows in the package publishing process.
1. Reproducible builds have to be mandatory
2. Deployed packages have no execution or network capability at install time
3. If package artifacts differ from source artifacts, block it temporarily
4. In order to defend against credentials harvesting: Package managers need to have mandatory container or sandbox isolation (mandatory bubblewrap, podman, or whatever isolation that segregates filesystems and networking)
5. In order to defend against github being abused as a C2 infrastructure: Package managers need to have locked behavioral rulesets of packages, "allow filesystem" or "allow networking" is useless, and needs to be per-resource. Additionally, it needs to be a mandatory allowlist-only enforcement. If it's allowed by default, it won't help with the transitive dependencies problem
6. Introduced transitive dependencies need to be locked and signed by the package repository authority.
7. In order to defend against eBPF Rootkit: Sorry, you're just f'cked. The only EDR on the market that defends against this attack surface is literally my own product (that I won't advertise here). Every other available tooling is just too outdated in how it has been developed, and too outdated how it's doing behavioral analytics of malware.
---
My personal take on this:
Pretty much every developer thinks this isn't necessary and is probably gonna downvote me for telling the security perspective here. This is not about what's necessary, this is about what's broken.
Our existing DevOps and DevSecOps culture and the involved incident response/supply chain security/GRC/etc workflows are absolutely broken against these reoccurring supply chain attacks, and the tooling that promised to catch this is also absolutely broken and useless against mutating malware that's co-generated by LLMs.
The only ones actually re-identifying the malware implants as miasma malware samples correctly were the socket.dev folks. Every other supply chain tool vendor was just bragging about a new malware campaign because they weren't up to speed and seemingly didn't know about the initial miasma campaigns (and the prototype campaign targeting RedHat's NPM packages with the gyp bindings).
Microsoft was so useless in its incident response workflow that they tried to mitigate the problem by making VSCode extension installs with a required delay time, not even having understood how the malware implants work, and not even having understood what the actual spread vector was.
It's like Microsoft had to press a red button just for the sake of having done anything, instead of openly communicating and advising to ongoing malware attacks, sharing intelligence and samples; and in consequence leaving every customer of Microsoft in the dark, getting compromised in the process, too.
[1] https://github.com/cookiengineer/antimiasma
[2] https://cookie.engineer/weblog/articles/malware-insights-mia...
A little bit of bureaucracy in form of best security practices helps with supply chain attacks.