Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dependabot version updates introduce default package cooldown

github.blog

Post reply on HN
Print view View original

51–60 of 154 posts

Re: Dependabot version updates introduce default package cooldown

#51

Post by tharkun__ »

stusmall wrote: post #22
zihotki wrote: post #15

If everyone starts applying cooldowns, won't it postpone the problem? So now there is a considerable amount of users who are affected and someone from the affected group discovers the infection and reports it. But if everyone will be delaying updates, won't be there less chances to catch it in time? I'm not fully sure if it's possible to preventively scan all NPM packages or how much compute it would require.

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

Re: Dependabot version updates introduce default package cooldown

#52

Post by Waterluvian »

JoshTriplett wrote: post #42
Waterluvian wrote: post #18

I really hate dependabot making generic security people at work so pushy about updates updates updates. They seem to just be dogmatic about whatever dependabot says, forcing churn even when the documented issues are clearly not relevant. I’m not sure how to handle it politically. I’m convinced that updating so much more often is worse, not better.

> I’m convinced that updating so much more often is worse, not better. The issue of cooldowns aside (which is about delaying updates, not reducing their frequency): you're going to have the same set of problems when you update, whether you do it frequently or infrequently. The difference is that if you update frequently, you'll have a smaller set of updates (so it's easier to debug) and you'll have more opportunity t…

My logical read of the situation is that I end up making fewer overall changes if I end up upgrading a dependency once, not thrice, to a specific version. And the changes are their own source of risk.

Re: Dependabot version updates introduce default package cooldown

#53

Post by woodruffw »

tharkun__ wrote: post #51
stusmall wrote: post #22

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…

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.

Re: Dependabot version updates introduce default package cooldown

#54

Post by tedivm »

tharkun__ wrote: post #51
stusmall wrote: post #22

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…

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.

Re: Dependabot version updates introduce default package cooldown

#55

Post by [deleted] »

Waterluvian wrote: post #18

I really hate dependabot making generic security people at work so pushy about updates updates updates. They seem to just be dogmatic about whatever dependabot says, forcing churn even when the documented issues are clearly not relevant. I’m not sure how to handle it politically. I’m convinced that updating so much more often is worse, not better.

[deleted]

Re: Dependabot version updates introduce default package cooldown

#57

Post by brikym »

zihotki wrote: post #15

If everyone starts applying cooldowns, won't it postpone the problem? So now there is a considerable amount of users who are affected and someone from the affected group discovers the infection and reports it. But if everyone will be delaying updates, won't be there less chances to catch it in time? I'm not fully sure if it's possible to preventively scan all NPM packages or how much compute it would require.

When you're running from a bear on a hiking trip you just have to be faster than your friend. So just set your cooldown slightly longer than everyone else's cooldowns. The cooldown will give security researchers some time to scan the packages so it's still good.

Re: Dependabot version updates introduce default package cooldown

#58

Post by tharkun__ »

tedivm wrote: post #54
tharkun__ wrote: post #51

Earlier quoted context omitted.

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…

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

Re: Dependabot version updates introduce default package cooldown

#59

Post by bitmasher9 »

kibwen wrote: post #30
noosphr wrote: post #26

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.

They are literally solving the same problem, it’s just that distro packages operate on a lower level and thus receive more scrutiny. There have been plenty of examples of poisoned Linux packages, both at the source level and at the package level.

Re: Dependabot version updates introduce default package cooldown

#60

Post by bitmasher9 »

Grokify wrote: post #56

This seems to be primarily an issue with a few specific package management solutions that have suffered SCA vulnerabilities recently, not generaly across the board.

It’s foolish to feel safe because your package management solution hasn’t been attacked yet.

The attack vector is generalized.

Post reply on HN