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"...
Author here - people are definitely looking at other places. This just happens to be where the attacks are, and gets disproportionate attention as a result.
Do you have examples of campaigns that weren’t flagged? Everything except xz had a 1 day window and Dependency Cooldowns are super effective against most campaigns for that reason.
Aliases and pre-hooks are nowhere near the guarantees you want, that’s what I am arguing - not everything is invoked from a blessed shell. Safely-bump-does.sh is also impossibly hard to write because you are replicating _all of the work NPM does in transitive dependency resolution_. Unless you are re-generating the lock file from scratch - it isn’t safe. Just updating package.json isn’t sufficient for eg.
My understanding is probably not: the hooks are configured locally, not by other packages automatically, so you’d install and setup the pre-install hooks yourself to check the packages before install/update.
Can it be exploited? Yes, anything can. But that’s not a reason to not do this if the overall result is better.
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.
> 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
Are you sure? I'm pretty sure .deb and .rpm packages both allow that
>Are you sure? I'm pretty sure .deb and .rpm packages both allow that
Learned something new today. Thanks.
I think the other significant issue with the NPM ecosystem that makes it bad in particular is NPM's dependency management is genuinely the worst out of any package manager because of phantom dependency is the default: you can be using a package without ever knowing that you are using it because it is imported implicitly, and the JS ecosystem dependency is so weird that taking down a small package that that a major project depends on cripples the entire JS ecosystem, as shown in left-pad, and launching a cyberattack via npm can be as easy as putting malicious code in any small package that large, popular packages depend on and watch it propagate. This is not hypothetical, it has been done, repeatedly in fact, over the years.
TS is a good programming language, however NPM is a security nightmare, and somehow the collective reaction of everyone depends on the JS/TS ecosystem seems like a shrug and "oh well, what can you do".
I wrote this in response to the recent AUR attacks. The problem isn’t really too many dependencies - it is that most users cannot be auditing everything they install and we need mechanisms that help users where they are.
I audit my AUR pkg builds, and I would have likely caught any malware. But so would a Dependency Cooldown or a third-party threat feed. Package Managers should make it easy to build this tooling via hooks.
Both certainly do. My own hypothesis on why this isn't a more widespread problem is the speed, or lack thereof, of these ecosystems. By the time a package hits debian stable, it's usually been under scrutiny for a year or more.
(Author here). It isn’t a matter of pre-install hooks. I don’t want known malware on my system irrespective of whether it runs at install-time or not. Pre-install hooks are going away in NPM, but we will have code injected in index.js next.
Modern package managers are not amenable to letting another script override its resolutions, and that is what needs fixing.
I’d even say perhaps we need a fine grained permission system like Apple provides, but for clis, not just something limited to maintainers of package managers.
>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.
(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.
No, you are exaggerating my point of view so that it's easier to dismiss and so you don't have to evaluate the proposition.
A mix of a Strawman and a false dilemma.
"Write more and use less third party, than you are currently using." would be more accurate.
Consider this, the package manager I use has not been infected in over a decade, the package manager you are suggesting improvements for is currently distributing malware as we speak.
Doesn't that invite you more to learn about our ways? It takes effort, especially if you consider what I'm writing to be a wall of text. But unless you consider 'shipping faster' to be a worthy tradeoff for cybersecurity, then it's worth it to learn, no?
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.
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"...
Do you have examples of campaigns that weren’t flagged? Everything except xz had a 1 day window and Dependency Cooldowns are super effective against most campaigns for that reason.
See papers at https://kokkonisd.github.io/ for eg.
2. This is clearly unacceptable, so we've created the one standard to unite them all™.
3. There are 6 competing standards.
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.
Can it be exploited? Yes, anything can. But that’s not a reason to not do this if the overall result is better.
But yeah, maybe through an exploit with a narrow reach. Once in, the malware can veto security updates and escalate to full control.
TFA is also a bit hazy on what hooks exactly?
homebrew doesn't support hooks as a system package manager: https://github.com/ecosyste-ms/package-manager-hooks as an example.
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.
Are you sure? I'm pretty sure .deb and .rpm packages both allow that
I think the other significant issue with the NPM ecosystem that makes it bad in particular is NPM's dependency management is genuinely the worst out of any package manager because of phantom dependency is the default: you can be using a package without ever knowing that you are using it because it is imported implicitly, and the JS ecosystem dependency is so weird that taking down a small package that that a major project depends on cripples the entire JS ecosystem, as shown in left-pad, and launching a cyberattack via npm can be as easy as putting malicious code in any small package that large, popular packages depend on and watch it propagate. This is not hypothetical, it has been done, repeatedly in fact, over the years.
TS is a good programming language, however NPM is a security nightmare, and somehow the collective reaction of everyone depends on the JS/TS ecosystem seems like a shrug and "oh well, what can you do".
I wrote this in response to the recent AUR attacks. The problem isn’t really too many dependencies - it is that most users cannot be auditing everything they install and we need mechanisms that help users where they are.
I audit my AUR pkg builds, and I would have likely caught any malware. But so would a Dependency Cooldown or a third-party threat feed. Package Managers should make it easy to build this tooling via hooks.
Modern package managers are not amenable to letting another script override its resolutions, and that is what needs fixing.
I’d even say perhaps we need a fine grained permission system like Apple provides, but for clis, not just something limited to maintainers of package managers.
well deno has the stuff... but deno's not popular (yet)
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.
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...
>Write everything yourself, don't use third party
No, you are exaggerating my point of view so that it's easier to dismiss and so you don't have to evaluate the proposition.
A mix of a Strawman and a false dilemma.
"Write more and use less third party, than you are currently using." would be more accurate.
Consider this, the package manager I use has not been infected in over a decade, the package manager you are suggesting improvements for is currently distributing malware as we speak.
Doesn't that invite you more to learn about our ways? It takes effort, especially if you consider what I'm writing to be a wall of text. But unless you consider 'shipping faster' to be a worthy tradeoff for cybersecurity, then it's worth it to learn, no?
Which package manager do you mean?
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.