4 ms·

Another fun fact to consider is that with many package formats, you can execute arbitrary code at install time so if a malicious package can get into a reposito

Another fun fact to consider is that with many package formats, you can execute arbitrary code at install time so if a malicious package can get into a repository, it's very likely to start compromising systems quickly. Whilst a package manager repo. compromise would be the biggest bang in terms of attack, compromising the credentials of the developers of popualar libraries would be an easier attack (and indeed is already happening https://twitter.com/chrispederick/status/892768218162487300 https://twitter.com/chrispederick/status/892768218162487300)

ams6110 9y ago
Doubly so since when installed on a server very often it will be done as "sudo pip install ....." (/s/pip/other-package-manager/ as needed)
- tekromancr 9y ago
  I almost never see this. Even on systems that are only running a single python project, I only ever see folks use virtualenv. The only time I ever see things installed with sudo is when the package is being installed in a docker container.
  - striking 9y ago
    This used to be super common, though. I see it all the time in legacy apps.
    - acdha 9y ago
      Yes – to the degree that it's uncommon now that's because many people in the community spent years loudly advising against it.
  - jefurii 9y ago
    > virtualenv Running "pip install" as a user that has access only to the virtualenv directory is sounding like a good strategy.
vosper 9y ago
With Python you can execute arbitrary code at import time... you don't even have to get to the install process. I've seen packages on Pypi that try to "sudo apt-get install ..." when the setup.py file is imported. Also, even without sudo there's absolutely nothing stopping you (for example) downloading a cryptocurrency miner, or DDOS tool, or something, and starting it up to run in the background.
acdha 9y ago
I was recently very surprised to see an expensive security scanner which builds apps as the service account apparently without sandboxing. A package manager which executes code or which is exploitable would give you access to what is very likely an interesting account & data, and in at least some cases might not leave many clues behind. PyPI, etc. at least has centralization and immutable versions but who knows what's serving some random repo, tarball, etc. which might not even be a direct dependency?

ams6110 9y ago

Doubly so since when installed on a server very often it will be done as "sudo pip install ....." (/s/pip/other-package-manager/ as needed)

tekromancr 9y ago
I almost never see this. Even on systems that are only running a single python project, I only ever see folks use virtualenv. The only time I ever see things installed with sudo is when the package is being installed in a docker container.
- striking 9y ago
  This used to be super common, though. I see it all the time in legacy apps.
  - acdha 9y ago
    Yes – to the degree that it's uncommon now that's because many people in the community spent years loudly advising against it.
- jefurii 9y ago
  > virtualenv Running "pip install" as a user that has access only to the virtualenv directory is sounding like a good strategy.

vosper 9y ago

With Python you can execute arbitrary code at import time... you don't even have to get to the install process. I've seen packages on Pypi that try to "sudo apt-get install ..." when the setup.py file is imported. Also, even without sudo there's absolutely nothing stopping you (for example) downloading a cryptocurrency miner, or DDOS tool, or something, and starting it up to run in the background.

acdha 9y ago

I was recently very surprised to see an expensive security scanner which builds apps as the service account apparently without sandboxing. A package manager which executes code or which is exploitable would give you access to what is very likely an interesting account & data, and in at least some cases might not leave many clues behind. PyPI, etc. at least has centralization and immutable versions but who knows what's serving some random repo, tarball, etc. which might not even be a direct dependency?