0

I "minimally trust" the PHP and PostgreSQL projects to provide non-compromised binaries of their respective programs, which I both depend on. This means that I trust them in the sense that I have no real choice but to trust them.

However, I have well over 100,000 lines of third-party PHP libraries (managed through Composer) which I also am forced to blindly trust in practice. Even if "Symphony" might be a large project, and perhaps not too likely to contain malicious injected code, there are various obscure PHP libs created by a single guy 5 years ago, who I'm forced to trust an equal amount. I do not trust those whatsoever, but I have no choice but trust that they don't log in to their Github account and make a change which steals all my data and have me auto-fetch it with the next time Composer runs its update mechanism.

(I don't even use Symphony myself. It's a massive dependency by some other third-party PHP library.)

Why is there no "protection layer" for this? I'd like to be able to tell PHP or Composer that "this library does not get to use the network connection whatsoever, and can only see this directory, and cannot launch any commands on its own", etc. You know, some kind of minimal protection layer to avoid a catastrophe when ObscureAuthor's little PHP library gets "hacked" on GitHub and starts sending my wallet.dats to some server in Russia.

At least with a security layer as I describe, the worst thing that could happen is that the library starts lying about numbers to my own application's scripts, but at least it cannot do fishy things freely over the network and stuff like that which I fear constantly.

PS: Please do not tell me "Docker". Docker is vaporware to me. I've tried to use it for literally many years but still haven't figured out how it's supposed to run, so no, it's not easy to use and not what I'm talking about. PS 2: I can't follow the advice to "use only major libraries" because extremely few libraries are anything but obscure and have a monopoly, meaning there are no alternatives.

Agusta Kallon
  • 9
  • 1
  • What you dismiss as a "minimal protection layer" (per library control of server resources regardless of dependencies) is no trivial task. Containerization ***is*** the method to segment the access running code can have. – schroeder Apr 21 '20 at 23:06
  • What you are missing is an understanding of the PHP technology stack and the difficulty of jamming a control layer at right angles in the middle of it. – schroeder Apr 21 '20 at 23:08

1 Answers1

0

Disclaimer: I am not a php expert, but this seems to be a question that pertains to package management in general.

Every package manager suffers from this, whether it is npm, composer, gem, etc.

npm (Node Package Manager) suffered from exactly this scenario a couple years back.

What some package managers do to mitigate this, is require repositories provide a cryptographic signature with the package being installed, so that if the package was tampered with and not signed by the owner, it will be flagged by the package manager.

Some package managers also do vulnerability scanning, for reported vulnerabilities in the version you are dependent on, so you know to upgrade.

Using third party software requires trust (on the developers, on the repository where it is imported from, on the software it depends on) for more than just security, and there are no silver bullets.

If your package manager does not do the minimum of package signing, then switch to one that does if possible or put pressure on them to do so.

If you have the backing to do so (I am not sure if this is a personal project or a work project), you (or your company) could set up your own repository that only contains packages you (or your company) has audited and configure your package manager to point to it. This keeps risk at a minimum, but requires quite a bit of effort.

iraleigh
  • 326
  • 2
  • 11