29 ms·

What happens when everyone adopts this policy? You just change it to two weeks?

by phoronixrly 5mo ago

deleted 5mo ago
[deleted]
Tomte 5mo ago
You rely on the security companies scanning the packages.
- exitb 5mo ago
  Well, if that actually works, it should be part of the release process, before the packages get placed onto the regular channels.
  - blm126 5mo ago
    I think the key right now is that these are semi-automated scanning processes. Right now, companies like step security selectively publish. So, in order for a hacking group to find out if their malware is detected or not, they have to burn access to a useful package. None of this is to say I think Microsoft shouldn't be doing something as part of the release process on NPM. However, there is real value in giving more independent third parties a window to do things semi-manually.
  - pixl97 5mo ago
    It works because there are multiple companies doing it and double checking the results. For example, is a crypto miner actually an attack? If the package presents itself as a miner, then no. Is connections to other repositories an attack? Again, depends on what the package does. Connections to some other hostname? Depends. There is still a lot of human analysis that occurs in making the call that an attack is occurring.
  - saghm 5mo ago
    Yeah, this is the part that I don't get. If the solution is "security testing should come before people install it", why is the big push to have people intentionally add this artificial delay to install later rather than moving the security testing earlier to before the release? If you want to make people not drive on the road until the pavement dries, you don't try to convince everyone to push back their workday by an hour; you just lay the asphalt an hour earlier.
- sandos 5mo ago
  Then the ... malware will just add delays? Or do they really do manual in-depth analysis of all new code? Just running and seeing it do things is probably a lot easier.
  - Ukv 5mo ago
    Security scanners won't be "manual in-depth analysis of all new code" or "Just running and seeing it do things", but somewhere in-between - utilizing static analysis/machine learning. It's a cat-and-mouse game, but the attacker adding code that waits X days to run something obfuscated would be another pattern that they could look for. I think these attackers are unlikely to add a delay in the first place because the chance of their attack being found out before it activates would be too high. They seem to generally work on the assumption that they have a day or so before the package is yanked (e.g: from maintainer noticing their account is compromised) so need to move fast.
- ZiiS 5mo ago
  @exitb it is much more desirable for security scanning companies to compete to find issues in a timely manor. If npm blessed one as a gatekeeper to the whole system they would be between a rock and a hard place. Unable to priorities high impact packages over the long tail of packages no one uses without pissing people off. Unable to add experimental new detections that may be a little noisy at first due to the huge disruption it would cause. Be trivial to game as obscure packages could brute-force their way though then use the same hole on a mainstream package.
BoredPositron 5mo ago
Always one day more than people on HN tell you. If something is compromised you will hear people complaining here that three days is not enough.
JoshTriplett 5mo ago
A large array of automated and semi-automated security scanners are finding things quickly. The main benefit of waiting before updating is to give those scanners time to work.
- genxy 5mo ago
  Would be nice if cargo had a cooldown flag and could respect lockfiles by default.
  - dbdr 5mo ago
    min-publish-age in cargo is coming: https://github.com/rust-lang/rfcs/blob/master/text/3923-cargo-min-publish-age.md https://github.com/rust-lang/rfcs/blob/master/text/3923-carg...
blm126 5mo ago
The one week cooldown option is not relying on other users to be a canary for you. Its just giving automated scanners a chance to notice. This is the perfect example. I don't think step security found this by accident. They are actively monitoring NPM package releases at some level. There is something to be said that Microsoft should be scanning packages pre-release. They aren't, though, so for right now there is a ton of value with very little downside if people implement a one week cooldown period. To answer your question directly, though. If everyone else moves to a one week cooldown, I would absolutely suggest a two week cooldown is a good idea. Being the "slow" moving organization is a good security trade-off so long as you don't take it to extremes and have escape hatches when you actually need to be moving quickly.
- phoronixrly 5mo ago
  Thank you for the thorough response. I got the following from yours and other responses: * The JS ecosystem has been and will most likely continue to be fast-moving, so it's quite a safe assumption that at no point will a quarantine period be wide-spread. * This quarantine period is for (semi-)automated scanners to catch the issue. Although considering the above there will always be a non-zero amount of end-user canaries as well. * Maybe NPM should run scanners before distributing malware? * If the ecosystem by any chance adopts a week-long quarantine period, you'd be safer if you applied a longer quarantine period.
  - _flux 5mo ago
    > Maybe NPM should run scanners before distributing malware? I suspect there's always a human checking these results. If NPM straight out rejects an update due to suspected malware, they might end up rejecting correct updates as well. If they grant some "safe" patterns a special pass, they might get exploited. So I think this only works if you have security scanners that are well-maintained and kept in secret. NPM folks could of course co-operate with some security companies to have a first stab with the releases before they are put to public access. At some point some parties might start want to have monetary compensation for such an arragnement, though.
bakugo 5mo ago
This will never happen unless it's made the default. Most people will always stick with the defaults.
Ukv 5mo ago
Security scans and authors realizing an unauthorized version was pushed will generally happen regardless of whether regular users updated. Even for compromises that are found by users updating, it'd generally be better to reduce the number of people affected with a slow roll-out rather than everyone jumping on at once.

What happens when everyone adopts this policy? You just change it to two weeks?

deleted 5mo ago

[deleted]

Tomte 5mo ago

You rely on the security companies scanning the packages.

exitb 5mo ago
Well, if that actually works, it should be part of the release process, before the packages get placed onto the regular channels.
- blm126 5mo ago
  I think the key right now is that these are semi-automated scanning processes. Right now, companies like step security selectively publish. So, in order for a hacking group to find out if their malware is detected or not, they have to burn access to a useful package. None of this is to say I think Microsoft shouldn't be doing something as part of the release process on NPM. However, there is real value in giving more independent third parties a window to do things semi-manually.
- pixl97 5mo ago
  It works because there are multiple companies doing it and double checking the results. For example, is a crypto miner actually an attack? If the package presents itself as a miner, then no. Is connections to other repositories an attack? Again, depends on what the package does. Connections to some other hostname? Depends. There is still a lot of human analysis that occurs in making the call that an attack is occurring.
- saghm 5mo ago
  Yeah, this is the part that I don't get. If the solution is "security testing should come before people install it", why is the big push to have people intentionally add this artificial delay to install later rather than moving the security testing earlier to before the release? If you want to make people not drive on the road until the pavement dries, you don't try to convince everyone to push back their workday by an hour; you just lay the asphalt an hour earlier.
sandos 5mo ago
Then the ... malware will just add delays? Or do they really do manual in-depth analysis of all new code? Just running and seeing it do things is probably a lot easier.
- Ukv 5mo ago
  Security scanners won't be "manual in-depth analysis of all new code" or "Just running and seeing it do things", but somewhere in-between - utilizing static analysis/machine learning. It's a cat-and-mouse game, but the attacker adding code that waits X days to run something obfuscated would be another pattern that they could look for. I think these attackers are unlikely to add a delay in the first place because the chance of their attack being found out before it activates would be too high. They seem to generally work on the assumption that they have a day or so before the package is yanked (e.g: from maintainer noticing their account is compromised) so need to move fast.
ZiiS 5mo ago
@exitb it is much more desirable for security scanning companies to compete to find issues in a timely manor. If npm blessed one as a gatekeeper to the whole system they would be between a rock and a hard place. Unable to priorities high impact packages over the long tail of packages no one uses without pissing people off. Unable to add experimental new detections that may be a little noisy at first due to the huge disruption it would cause. Be trivial to game as obscure packages could brute-force their way though then use the same hole on a mainstream package.

BoredPositron 5mo ago

Always one day more than people on HN tell you. If something is compromised you will hear people complaining here that three days is not enough.

JoshTriplett 5mo ago

A large array of automated and semi-automated security scanners are finding things quickly. The main benefit of waiting before updating is to give those scanners time to work.

genxy 5mo ago
Would be nice if cargo had a cooldown flag and could respect lockfiles by default.
- dbdr 5mo ago
  min-publish-age in cargo is coming: https://github.com/rust-lang/rfcs/blob/master/text/3923-cargo-min-publish-age.md https://github.com/rust-lang/rfcs/blob/master/text/3923-carg...

blm126 5mo ago

The one week cooldown option is not relying on other users to be a canary for you. Its just giving automated scanners a chance to notice. This is the perfect example. I don't think step security found this by accident. They are actively monitoring NPM package releases at some level. There is something to be said that Microsoft should be scanning packages pre-release. They aren't, though, so for right now there is a ton of value with very little downside if people implement a one week cooldown period. To answer your question directly, though. If everyone else moves to a one week cooldown, I would absolutely suggest a two week cooldown is a good idea. Being the "slow" moving organization is a good security trade-off so long as you don't take it to extremes and have escape hatches when you actually need to be moving quickly.

phoronixrly 5mo ago
Thank you for the thorough response. I got the following from yours and other responses: * The JS ecosystem has been and will most likely continue to be fast-moving, so it's quite a safe assumption that at no point will a quarantine period be wide-spread. * This quarantine period is for (semi-)automated scanners to catch the issue. Although considering the above there will always be a non-zero amount of end-user canaries as well. * Maybe NPM should run scanners before distributing malware? * If the ecosystem by any chance adopts a week-long quarantine period, you'd be safer if you applied a longer quarantine period.
- _flux 5mo ago
  > Maybe NPM should run scanners before distributing malware? I suspect there's always a human checking these results. If NPM straight out rejects an update due to suspected malware, they might end up rejecting correct updates as well. If they grant some "safe" patterns a special pass, they might get exploited. So I think this only works if you have security scanners that are well-maintained and kept in secret. NPM folks could of course co-operate with some security companies to have a first stab with the releases before they are put to public access. At some point some parties might start want to have monetary compensation for such an arragnement, though.

bakugo 5mo ago

This will never happen unless it's made the default. Most people will always stick with the defaults.

Ukv 5mo ago

Security scans and authors realizing an unauthorized version was pushed will generally happen regardless of whether regular users updated. Even for compromises that are found by users updating, it'd generally be better to reduce the number of people affected with a slow roll-out rather than everyone jumping on at once.