malicious entry points can be installed from *any* python package

[Morgan Fainberg]

With the way some projects consume stevedore (notably openstackclient) where entry points are loaded automatically, it is possible that *any* python package to install a malicious entrypoint that could modify/consume/expose/steal/etc just about any data that is passed through the client (due to the way that python works).

This is effectively a similar problem to the ld.so.preload with C programs on linux.

Based upon limited discussions it would be nice to allow a consumer of stevedore to provide a mechanism to "white-list" libraries. This is only one option proposed. :Likely the discussion is going to be more in depth.

[Morgan Fainberg (mdrnstm)]

This is likely an Class B2 type bug [1], based on bad architecture. Likely this needs an OSSN, which is published shortly after the bug is made public. I expect this bug will not remain private too terribly long.

[1] https://security.openstack.org/vmt-process.html#incident-report-taxonomy

[Jeremy Stanley (fungi)]

Also the VMT is currently neither covering stevedore nor python-openstackclient, though we're happy to provide guidance on triage and messaging as time allows.

[Doug Hellmann (doug-hellmann)]

Two thoughts on mitigation:

1. We could unset any auth-related environment variables before loading commands when help (the only case when we indiscriminately load code, afaict) to hide the values from plugins, which would then need to ask the app for an auth handle and we don't let them do that during help.
2. We could add a check using the EnabledExtensionManager to require plugins to be installed into the global site-packages (or more flexibly, into the same site-packages where python-openstackclient is installed).

I agree with Morgan that we should also document this.

[Jeremy Stanley (fungi)]

I'm unsure hiding the calling environment would solve anything. If the risk is that foo --help may load an untrusted (yet, for some reason, installed) entrypoint and run arbitrary code it provides, it's still a vector to modify dotfiles in the homedir, inspect files readable by that user, et cetera. Easy enough for it to leave behind a trap at that point to send interesting envvars to the attacker after the next login.

[Doug Hellmann (doug-hellmann)]

I'm inclined to say this is working as designed and just document it, but I don't want that documentation to be alarmist. I'm open to suggestions on wording if someone wants to propose something.