Advisories for Pypi/DIRAC package

Details A number of the functions in PilotManager pass parameters directly through to the database layer, which then does not do any escaping on the parameters. For example setPilotStatus: https://github.com/DIRACGrid/DIRAC/blob/1738e7c6d2f31d26f1364255d9d2e87b4896c922/src/DIRAC/WorkloadManagementSystem/Service/PilotManagerHandler.py#L343-L349 https://github.com/DIRACGrid/DIRAC/blob/1738e7c6d2f31d26f1364255d9d2e87b4896c922/src/DIRAC/WorkloadManagementSystem/DB/PilotAgentsDB.py#L117 This won't accept multiple statements separated by a semicolon, but a carefully crafted set of parameters containing SQL escapes would likely be able to change or return other database entries. Further to this, the PilotManager access control is only …

The second stage pilot (pilot.tar) is downloaded by the initial wrapper script without any verification of the webservers' SSL certificate and the contained script is subsequently executed. The checksum is tested, but the reference checksum file is downloaded over the same unvalidated channel.

An remote code execution vulnerability exists in RequestManager due to the use of eval on untrusted input that allows any authenticated user to run code/commands on the DIRAC server as the system user running the DIRAC services.

The FileCatalog DatasetManager runs a query on the database and passes the result to eval. The SQL query contains an injection vulnerability which allows an authenticated user to control the parameter returned to the eval resulting in remote code execution.

During the proxy generation process (e.g., when using dirac-proxy-init) it is possible for unauthorized users on the same machine to gain read access to the proxy. This allows the user to then perform any action that is possible with the original proxy. This vulnerability only exists for a short period of time (sub-millsecond) during the generation process.

Any user could get a token that has been requested by another user/agent