101–110 of 154 posts
So you exploit on Tuesday 12pm, dependabot opens a PR on Friday 12pm, people merge it, and your trojan's timer is set to go off over the weekend when nobody is patching.
Earlier quoted context omitted.
Publishing publicly then applying cooldowns in projects is much easier tgan establishing a new standard for pre-release security testing versions that works across ecosystems and gains zooling support.
Releasing secure software is the right thing to do. We only release insecure software because we need the eyeballs to make it secure. If we believe the point made above that the many eyeballs are not that important then releasing before we have done everything to make the software as secure as possible is irresponsible.
Watching language package managers reinvent everything distribution package managers have been doing since the 90s has been as fun as watching crypto people reinvent financial regulation.
This comparison is tiresome. Distro package managers are curated, language package managers are not. They're serving completely different use cases; the former is the App Store, the latter is the web.
But actually your comparison is incorrect, distros are nothing like app stores. App stores are full of the same junk and malware as language package managers. Distros are vetted collections of real software that use modern best practices to secure the software supply chain.
Earlier quoted context omitted.
This comparison is tiresome. Distro package managers are curated, language package managers are not. They're serving completely different use cases; the former is the App Store, the latter is the web.
I agree it's tiresome that language package managers continue to be an embarrassment. But actually your comparison is incorrect, distros are nothing like app stores. App stores are full of the same junk and malware as language package managers. Distros are vetted collections of real software that use modern best practices to secure the software supply chain.
(This is, to be clear, fine. But we should be clear-headed about what package distribution mechanisms actually provide in terms of guarantees.)
[1]: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1461834
https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...
Earlier quoted context omitted.
> But if everyone will be delaying updates, won't be there less chances to catch it in time? No: the security assumption behind cooldowns rests on security scanning parties, not on innocent users being victimized. Three days is a short cooldown, but it should be a good enough lead for scanning parties. > I'm not fully sure if it's possible to preventively scan all NPM packages or how much compute it would require. It…
Do you have an example of those things you're alleging? All package malware related news I see are related to users being affected by it (then security firms do their analysis whatever) ...
Earlier quoted context omitted.
>If everyone starts applying cooldowns, won't it postpone the problem? There are still research firms who are actively and aggressively scanning new packages once they are pushed. For example socket.dev pulls new packages across ecosystems and performs automated analysis and runs it in a sandbox. We don't have to have them go boom in someone's production repos to find out there is a problem.
And if every malware developer worth their salt now introduces code to "wait out" that period of time, we're back to square one. This assumes that they employ clandestine enough techniques that you have to actually install, wait and observe the behavior for longer than the cooldown period in order to detect this, because the code is "obfuscated" enough to evade static analysis of the code. It's anti-virus / anti-anti…
Of course this is an arms race, but the time setting inside the sandbox doesn't need to be the same as outside.
Earlier quoted context omitted.
Most automated analysis isn't dependent on just behavior, but rather suspicious things in the code itself. You have a popular open source package with files that exist on pypi but not github then that's a big flag, or if a similar package suddenly has some base64encoded garbage that runs through an obfuscated exec call. In other words the simple fact that the project has obfuscated code is enough to flag for further…
Cat and mouse like the sibling says ;) Like if you start changing system time, I'll keep a log of system time to detect any "jumps" and then "behave normally" if I detect this. Of course I'll run the code that does this through "my obfuscator". The thing with cat and mouse based on time is that this now became a default. I rather liked my odds when malware authors assumed that the defaults were that dependabot update…
This makes no sense, the system clock would be set before the suspect package is even pulled down. There isn't a "jump" just a reboot and system start at a "totally real" point in time.
And the premise is that this package can evade detection of its suspect code by using an ever-increasing amount of odd code? Yeah, that's a hard strategy.
Earlier quoted context omitted.
Most automated analysis isn't dependent on just behavior, but rather suspicious things in the code itself. You have a popular open source package with files that exist on pypi but not github then that's a big flag, or if a similar package suddenly has some base64encoded garbage that runs through an obfuscated exec call. In other words the simple fact that the project has obfuscated code is enough to flag for further…
Cat and mouse like the sibling says ;) Like if you start changing system time, I'll keep a log of system time to detect any "jumps" and then "behave normally" if I detect this. Of course I'll run the code that does this through "my obfuscator". The thing with cat and mouse based on time is that this now became a default. I rather liked my odds when malware authors assumed that the defaults were that dependabot update…
Earlier quoted context omitted.
>If everyone starts applying cooldowns, won't it postpone the problem? There are still research firms who are actively and aggressively scanning new packages once they are pushed. For example socket.dev pulls new packages across ecosystems and performs automated analysis and runs it in a sandbox. We don't have to have them go boom in someone's production repos to find out there is a problem.
If it is about a few highly specialized firms finding the vulns we should let them do it before publication and we do not need cooldowns. If it is not about that and we still subscribe to Linus's law then cooldowns will just postpone the problem.