5 ms·

More supply-chain attacks, though these (clickbait package names, monetized with referral links) are certainly less sophisticated and less dangerous than the wa

by fwlr 4y ago

More supply-chain attacks, though these (clickbait package names, monetized with referral links) are certainly less sophisticated and less dangerous than the wave that hit PyPI (typos of common package names, monetized by altering crypto addresses in your clipboard / paste buffer). As they say, the best time to start mitigating these attacks was 10 years ago; the next best time is today.

ok123456 4y ago
I'm now double and triple checking when I add a package to the manifest. You have to check not only that it's the right package, you also check that it has the number of downloads that you're expecting.
- z3t4 4y ago
  You should also read the source code. Developers are probably the only profession that blindly trusts their peers.
  - scarby2 4y ago
    most engineers blindly trust things when another engineer or vendor has signed off/certified on it. There's simply not enough time in the world to go through the certification date for every single part you use in a project. We trust that there has been a testing process that validates that things do what they say they will do. Admittedly when dealing with non-OSS vendors you can sue them if something goes badly wrong.
  - dgb23 4y ago
    It’s perfectly normal to trust your peers in a collaborative setting regardless of the profession. The issue is rather that this is only a largely collaborative one. Which makes the thing kind of worse, because you can _often_ get away with simply trusting everyone and there are economic and practical pressures to do so.
- ashishbijlani 4y ago
  The problem with using downloads as a proxy for "safety" is that a bad actor can use CI infra/bots/scripts to inflate the number. This is why in Packj [1] we check for multiple attributes (e.g., dependents). 1. https://github.com/ossillate-inc/packj https://github.com/ossillate-inc/packj
  - ok123456 4y ago
    I just tried this and the output is very very very noisy. It treats any dependent package that hasn't been updated in a while as a "RISK" and it manually tries to resolve each github repository (and runs into API request limits).
    - ashishbijlani 4y ago
      We've made it highly customizable [1]. For some folks, a package that has not been updated for a while could be classified as abandonware. You can turn off the alerts that do not apply to you by commenting out in .packj.yaml file. We're working on making it similar to email spam. Will post more soon. Meanwhile, we welcome changes that can make it less noisy for the community. [Edit:] one can specify Github API token to get around rate limiting. We'd deeply appreciate if could create an issue for this on the repo. 1. https://github.com/ossillate-inc/packj#customization https://github.com/ossillate-inc/packj#customization
thenerdhead 4y ago
I don't quite agree with your ancient Chinese proverb here. While it is ideal, we don't live in an ideal world. The world would have to be aware of these attack vectors and attack tactics to be able to mitigate them. That's not to say they haven't existed in concept for the last 10 years (which many have), just that very few utilized them maliciously until the last few years across the industry. (Also see the exponential increase of supply chain attacks in the last couple years alone and the vector/tactics used) Security tends to be a cat and mouse game in my experience. If you wanted to even go down the Sun Tzu perspective, the best defense is to subdue the enemy without fighting. That allows one to understand the strengths and weaknesses of one and their enemy and to develop a defense that is flexible and adaptable to the moment and harden it for the future.
- fwlr 4y ago
  To be specific, I was thinking that around the same time we started earnestly working on browser sandboxing and fine-grained extension/app privileges, we should have been doing the same thing for our packages. When Joe Normal tries to install an extension, Chrome tells him it wants to access his microphone; we could have had a similar thing here. “tennsserflow.py requests permission to modify the root filesystem”, “PERM: free-fortnite-skin asks to open URLs. grant / deny / uninstall ?”, etc.
  - dgb23 4y ago
    This needs support at the language/runtime level to be even remotely robust. Especially when we’re talking about highly dynamic and popular languages like JS/Python etc.
  - thenerdhead 4y ago
    Here's a helpful analogy that represents a problem per line: We download code From the internet Written by unknown individuals That we haven't read Which we execute With full permissions On our trusted devices Where we keep our most important data

by fwlr 4y ago

ok123456 4y ago

I'm now double and triple checking when I add a package to the manifest. You have to check not only that it's the right package, you also check that it has the number of downloads that you're expecting.

z3t4 4y ago
You should also read the source code. Developers are probably the only profession that blindly trusts their peers.
- scarby2 4y ago
  most engineers blindly trust things when another engineer or vendor has signed off/certified on it. There's simply not enough time in the world to go through the certification date for every single part you use in a project. We trust that there has been a testing process that validates that things do what they say they will do. Admittedly when dealing with non-OSS vendors you can sue them if something goes badly wrong.
- dgb23 4y ago
  It’s perfectly normal to trust your peers in a collaborative setting regardless of the profession. The issue is rather that this is only a largely collaborative one. Which makes the thing kind of worse, because you can _often_ get away with simply trusting everyone and there are economic and practical pressures to do so.
ashishbijlani 4y ago
The problem with using downloads as a proxy for "safety" is that a bad actor can use CI infra/bots/scripts to inflate the number. This is why in Packj [1] we check for multiple attributes (e.g., dependents). 1. https://github.com/ossillate-inc/packj https://github.com/ossillate-inc/packj
- ok123456 4y ago
  I just tried this and the output is very very very noisy. It treats any dependent package that hasn't been updated in a while as a "RISK" and it manually tries to resolve each github repository (and runs into API request limits).
  - ashishbijlani 4y ago
    We've made it highly customizable [1]. For some folks, a package that has not been updated for a while could be classified as abandonware. You can turn off the alerts that do not apply to you by commenting out in .packj.yaml file. We're working on making it similar to email spam. Will post more soon. Meanwhile, we welcome changes that can make it less noisy for the community. [Edit:] one can specify Github API token to get around rate limiting. We'd deeply appreciate if could create an issue for this on the repo. 1. https://github.com/ossillate-inc/packj#customization https://github.com/ossillate-inc/packj#customization

thenerdhead 4y ago

I don't quite agree with your ancient Chinese proverb here. While it is ideal, we don't live in an ideal world. The world would have to be aware of these attack vectors and attack tactics to be able to mitigate them. That's not to say they haven't existed in concept for the last 10 years (which many have), just that very few utilized them maliciously until the last few years across the industry. (Also see the exponential increase of supply chain attacks in the last couple years alone and the vector/tactics used) Security tends to be a cat and mouse game in my experience. If you wanted to even go down the Sun Tzu perspective, the best defense is to subdue the enemy without fighting. That allows one to understand the strengths and weaknesses of one and their enemy and to develop a defense that is flexible and adaptable to the moment and harden it for the future.

fwlr 4y ago
To be specific, I was thinking that around the same time we started earnestly working on browser sandboxing and fine-grained extension/app privileges, we should have been doing the same thing for our packages. When Joe Normal tries to install an extension, Chrome tells him it wants to access his microphone; we could have had a similar thing here. “tennsserflow.py requests permission to modify the root filesystem”, “PERM: free-fortnite-skin asks to open URLs. grant / deny / uninstall ?”, etc.
- dgb23 4y ago
  This needs support at the language/runtime level to be even remotely robust. Especially when we’re talking about highly dynamic and popular languages like JS/Python etc.
- thenerdhead 4y ago
  Here's a helpful analogy that represents a problem per line: We download code From the internet Written by unknown individuals That we haven't read Which we execute With full permissions On our trusted devices Where we keep our most important data