6 ms·

>If everyone starts applying cooldowns, won't it postpone the problem? There are still research firms who are actively and aggressively scanning new packages o

>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.

NewJazz 3mo ago
Also as an upstream, if your "coworker" releases a strange package without discussing the changes with the broader maintenance group, you might notice after 3-48 hours, but probably not within the hour unless you happened to be online.
tharkun__ 3mo ago
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-virus 101 all over so to speak. The good thing I suppose is that it raises the bar. Your regular "virus generator" script kid (sorry: supply chain attack generator script kid) can no longer pull this off.
- woodruffw 3mo ago
  Fundamentally, this is a cat-and-mouse game. But I suspect that "time bomb" techniques aren't economically viable for attackers, at least not with current patterns: current attackers demonstrate "smash and grab" tendencies because they know their access is limited anyways. Attempting to wait out a cooldown exposes them to additional detection risk. Of course, maybe the attacker profile changes over time. But that's the nature of the game.
- tedivm 3mo ago
  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 attention. That said if the only issue is time, researchers will just run their automated analysis through machines with dates in the future alongside their normal tests.
  - tharkun__ 3mo ago
    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 updates right away. If the general consensus online seems to be 7 days, then I'll set my dependabot to wait 10 days, so on average I'll catch even things people report over a weekend. Now that the default is a longer time period, I have to change my time period to be even longer, which actually increases my risk in another way: I'll stay vulnerable to _actual_ vulnerabilities vs. supply chain attacks for longer.
    - mplewis 3mo ago
      ok, but your package still contains obfuscated code that we can read
    - SideburnsOfDoom 3mo ago
      > I'll keep a log of system time to detect any "jumps" and then "behave normally" if I detect this. 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.
    - 3mo ago
- mgrandl 3mo ago
  This would increase the malware surface area and make it much easier for automated security scanners to detect. So win-win for everyone.
- tcoff91 3mo ago
  You can simulate accelerated time in the sandbox used to evaluate the runtime behavior of the package being analyzed.
- SideburnsOfDoom 3mo ago
  > And if every malware developer worth their salt now introduces code to "wait out" that period of time, we're back to square one. Of course this is an arms race, but the time setting inside the sandbox doesn't need to be the same as outside.
  - tharkun__ 3mo ago
    That's a fair enough thing to say but then also setting the default to 7 days is no longer a necessity, because security researchers can automate running a new version through an accelerated time sandbox, can't they? And no they can't and is probably why this change is happening to dependabot: A common pattern is sampling time before and after a sleep/timer, then aborting/delaying if the sandbox looks like it accelerated time by having a 1s sleep timer expire after 0.1s. Malware would also try to use different time sources and try to correlate them. And yeah, like you say as well, of course its an arms race in the same way that back in the day state of the art viruses and worms were and anti-virus software was. And personally I still liked it more when malware/supply chain attack actors assumed everyone was upgrading within a day or two while I was doing it after 7. You don't have to outrun the lion, just the guy slower than you and who's between you and the lion ;)
weinzierl 3mo ago
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.
- StrauXX 3mo ago
  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.
  - yuppiepuppie 3mo ago
    Exactly this. The firms can follow the standard practices of the industry without needing to injection further process into the projects.
  - weinzierl 3mo ago
    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.
    - palky 3mo ago
      "We only release insecure software because we need the eyeballs to make it secure." No one is doing this on purpose, they believe the software to be secure when they release it... You shouldn't gate the release of a package until every single offsec research shop in the world has had a chance to look at it
- rcxdude 3mo ago
  The cooldowns effectively make the initial push into the package repository into a pre-publishing step. It's pretty much isomorphic with what you're suggesting.

NewJazz 3mo ago

Also as an upstream, if your "coworker" releases a strange package without discussing the changes with the broader maintenance group, you might notice after 3-48 hours, but probably not within the hour unless you happened to be online.

tharkun__ 3mo ago

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-virus 101 all over so to speak. The good thing I suppose is that it raises the bar. Your regular "virus generator" script kid (sorry: supply chain attack generator script kid) can no longer pull this off.

woodruffw 3mo ago
Fundamentally, this is a cat-and-mouse game. But I suspect that "time bomb" techniques aren't economically viable for attackers, at least not with current patterns: current attackers demonstrate "smash and grab" tendencies because they know their access is limited anyways. Attempting to wait out a cooldown exposes them to additional detection risk. Of course, maybe the attacker profile changes over time. But that's the nature of the game.
tedivm 3mo ago
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 attention. That said if the only issue is time, researchers will just run their automated analysis through machines with dates in the future alongside their normal tests.
- tharkun__ 3mo ago
  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 updates right away. If the general consensus online seems to be 7 days, then I'll set my dependabot to wait 10 days, so on average I'll catch even things people report over a weekend. Now that the default is a longer time period, I have to change my time period to be even longer, which actually increases my risk in another way: I'll stay vulnerable to _actual_ vulnerabilities vs. supply chain attacks for longer.
  - mplewis 3mo ago
    ok, but your package still contains obfuscated code that we can read
  - SideburnsOfDoom 3mo ago
    > I'll keep a log of system time to detect any "jumps" and then "behave normally" if I detect this. 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.
  - 3mo ago
mgrandl 3mo ago
This would increase the malware surface area and make it much easier for automated security scanners to detect. So win-win for everyone.
tcoff91 3mo ago
You can simulate accelerated time in the sandbox used to evaluate the runtime behavior of the package being analyzed.
SideburnsOfDoom 3mo ago
> And if every malware developer worth their salt now introduces code to "wait out" that period of time, we're back to square one. Of course this is an arms race, but the time setting inside the sandbox doesn't need to be the same as outside.
- tharkun__ 3mo ago
  That's a fair enough thing to say but then also setting the default to 7 days is no longer a necessity, because security researchers can automate running a new version through an accelerated time sandbox, can't they? And no they can't and is probably why this change is happening to dependabot: A common pattern is sampling time before and after a sleep/timer, then aborting/delaying if the sandbox looks like it accelerated time by having a 1s sleep timer expire after 0.1s. Malware would also try to use different time sources and try to correlate them. And yeah, like you say as well, of course its an arms race in the same way that back in the day state of the art viruses and worms were and anti-virus software was. And personally I still liked it more when malware/supply chain attack actors assumed everyone was upgrading within a day or two while I was doing it after 7. You don't have to outrun the lion, just the guy slower than you and who's between you and the lion ;)

weinzierl 3mo ago

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.

StrauXX 3mo ago
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.
- yuppiepuppie 3mo ago
  Exactly this. The firms can follow the standard practices of the industry without needing to injection further process into the projects.
- weinzierl 3mo ago
  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.
  - palky 3mo ago
    "We only release insecure software because we need the eyeballs to make it secure." No one is doing this on purpose, they believe the software to be secure when they release it... You shouldn't gate the release of a package until every single offsec research shop in the world has had a chance to look at it
rcxdude 3mo ago
The cooldowns effectively make the initial push into the package repository into a pre-publishing step. It's pretty much isomorphic with what you're suggesting.