8 ms·

Package managers seem to be an increasingly popular attack vector. It's only luck that none of the attacks have been particularly malicious yet. Considering how

Package managers seem to be an increasingly popular attack vector. It's only luck that none of the attacks have been particularly malicious yet. Considering how many package manager downloads go to a server in a datacenter, a widely distributed malicious package could control a botnet with extremely high throughput, or wreak havoc on any databases it comes into contact with. It's only a matter of time before something like this happens. A big part of the problem is that application package managers, like pip or npm, are far less sophisticated than those of operating systems, like aptitude or yum. It needs to be easy for developers to open source their code, and to mark dependencies with precise commit hashes, but the download also needs to be secure and verifiable. There are many difficult tradeoffs to consider in terms of usability, centralization, security and trust.

raesene6 9y ago
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?
mtkd 9y ago
More needs to be done by package managers to warn end users. One scenario that worries me is where apps age and use popular trusted dependancies (e.g. gems on Github). When those gems stop being maintained but need to be updated to work (say with latest OSX) - it's common to quickly look at the latest forks available and select the one that now works correctly - but without a detailed inspection of the new code it's potentially kryptonite for a production datacenter.
- raesene6 9y ago
  Package managers are providing (in the most case) a free service, so it's hard to see a strong case for them providing more services here. The problem is one of scale. npm has over 500,000 packages, so no manual review will address their scale over the whole repository. Until the developer market shows that they'll pay for a more secure service (e.g. package signed, reviews done etc) I doubt much will change.
  - mbrock 9y ago
    Maybe most of those 500,000 packages simply shouldn't be trusted. There's a precedent for curated subsets of package ecosystems. Stackage for Haskell is an example, although it doesn't have security as the primary goal. I don't think we should focus on actual audits of packages. Just checking that packages seem basically credible seems like a better approach because it's doable.
    - raesene6 9y ago
      Credibility is an easier check but still tricky. Many of the package are uploaded by anonymous or pseudonymous authors, so there's no easy way to even tie that to an IRL identity, let alone check for credibility. I'd agree that a curated small package repository would be a better way to address the problem, but the market doesn't seem very interested in that as a solution.
      - mbrock 9y ago
        I think it might just not have happened yet. The npm community can be pretty creative and enthusiastic! I don't think IRL identities are necessary for what I imagine. It's more like establishing a basic set of packages that have been around, have communities of committers, reverse dependencies, etc. Maybe we would even make a starting assumption that the transitive closure of dependencies originating with a set of high profile packages are "approved". I'm thinking aloud but I think there could be a reasonably pragmatic way to get this started...
edanm 9y ago
It's also very possible that a far more malicious attack has happened, but not been discovered.
jeffson256 9y ago
I'm always fascinated by the amount of trust being exhibited by the developers of some node projects I've seen. Their projects have an order of magnitude more dependencies than I'm used to - and at the other end of each one is someone publishing some small module to npm with an unknown amount of review. I feel safe(r) installing dependencies from apt because I know the processes the Debian community follows before packages are included in the official repos.
avsm 9y ago
This is why we are working on integrating TUF (The Update Framework) signing into the OCaml OPAM package manager. See https://github.com/hannesm/conex-paper/blob/master/paper.pdf https://github.com/hannesm/conex-paper/blob/master/paper.pdf for the talk from last year. There's one more iteration required on the implementation before we're happy with it, but we are aiming to get this live on the OPAMv2 package repository some time in 2018 for all the publicly available OCaml packages. OPAMv2 also exposes sufficient hooks during the build process for using OS sandboxing during builds, and disconnecting network access/etc. It would be nice to factor this out to be more OS independent (e.g. for all the `unshare` tricks on Linux, or the sexp-format for sandboxing on OSX) in the future.

raesene6 9y ago

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?

mtkd 9y ago

More needs to be done by package managers to warn end users. One scenario that worries me is where apps age and use popular trusted dependancies (e.g. gems on Github). When those gems stop being maintained but need to be updated to work (say with latest OSX) - it's common to quickly look at the latest forks available and select the one that now works correctly - but without a detailed inspection of the new code it's potentially kryptonite for a production datacenter.

raesene6 9y ago
Package managers are providing (in the most case) a free service, so it's hard to see a strong case for them providing more services here. The problem is one of scale. npm has over 500,000 packages, so no manual review will address their scale over the whole repository. Until the developer market shows that they'll pay for a more secure service (e.g. package signed, reviews done etc) I doubt much will change.
- mbrock 9y ago
  Maybe most of those 500,000 packages simply shouldn't be trusted. There's a precedent for curated subsets of package ecosystems. Stackage for Haskell is an example, although it doesn't have security as the primary goal. I don't think we should focus on actual audits of packages. Just checking that packages seem basically credible seems like a better approach because it's doable.
  - raesene6 9y ago
    Credibility is an easier check but still tricky. Many of the package are uploaded by anonymous or pseudonymous authors, so there's no easy way to even tie that to an IRL identity, let alone check for credibility. I'd agree that a curated small package repository would be a better way to address the problem, but the market doesn't seem very interested in that as a solution.
    - mbrock 9y ago
      I think it might just not have happened yet. The npm community can be pretty creative and enthusiastic! I don't think IRL identities are necessary for what I imagine. It's more like establishing a basic set of packages that have been around, have communities of committers, reverse dependencies, etc. Maybe we would even make a starting assumption that the transitive closure of dependencies originating with a set of high profile packages are "approved". I'm thinking aloud but I think there could be a reasonably pragmatic way to get this started...

edanm 9y ago

It's also very possible that a far more malicious attack has happened, but not been discovered.

jeffson256 9y ago

I'm always fascinated by the amount of trust being exhibited by the developers of some node projects I've seen. Their projects have an order of magnitude more dependencies than I'm used to - and at the other end of each one is someone publishing some small module to npm with an unknown amount of review. I feel safe(r) installing dependencies from apt because I know the processes the Debian community follows before packages are included in the official repos.

avsm 9y ago

This is why we are working on integrating TUF (The Update Framework) signing into the OCaml OPAM package manager. See https://github.com/hannesm/conex-paper/blob/master/paper.pdf https://github.com/hannesm/conex-paper/blob/master/paper.pdf for the talk from last year. There's one more iteration required on the implementation before we're happy with it, but we are aiming to get this live on the OPAMv2 package repository some time in 2018 for all the publicly available OCaml packages. OPAMv2 also exposes sufficient hooks during the build process for using OS sandboxing during builds, and disconnecting network access/etc. It would be nice to factor this out to be more OS independent (e.g. for all the `unshare` tricks on Linux, or the sexp-format for sandboxing on OSX) in the future.