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.
>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. Today they describe the program behavior, not the program structure, so 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.
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.
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?
This sounds like a prime new vector for malware, ironically.
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.
>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. Today they describe the program behavior, not the program structure, so 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.
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.
That’s just a wall of text for “malware detection is hard, write everything yourself, don’t use third party”. Thanks for the insight, I guess.
>Malware detection is hard Hell yeah
>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?
"Consider this, the package manager I use has not been infected in over a decade [..]"
Which package manager do you mean?