Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 set to "authenticated"; this allows these functions to be called by any user. This allows any user to manage (e.g. delete, read output of) any pilot pilot job:…
Recommended action: Upgrade to 9.1.10, 9.0.22 or 8.0.79 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details The pilot wrapper downloads and executes the main second stage pilot script, but the SSL validation on this connection is explicitly disabled (to match old python < 2.7.9 behaviour): https://github.com/DIRACGrid/DIRAC/blob/integration/src/DIRAC/WorkloadManagementSystem/Utilities/PilotWrapper.py#L292-L296 This means that the second stage pilot code is not verified in any way and could potentially be altered by a man-in-the-middle attack to execute arbitrary code in the pilot context (i.e. with access to the pilot proxy/credentials). The HTTPS connection should be validated against both the system certificates and $X509CERTDIR and fail if neither validate correctly. Impact This…
Recommended action: Upgrade to 9.1.10, 9.0.22 or 8.0.79 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details The FileCatalog checkDataset function passes its datasets argument directly to the backend DB handler: https://github.com/DIRACGrid/DIRAC/blob/f7e0a3ac153315030fb3520e8ca747f013758967/src/DIRAC/DataManagementSystem/Service/FileCatalogHandler.py#L591-L593 Which in turn passes it to the checkDataset function: https://github.com/DIRACGrid/DIRAC/blob/f7e0a3ac153315030fb3520e8ca747f013758967/src/DIRAC/DataManagementSystem/DB/FileCatalogComponents/DatasetManager/DatasetManager.py#L390 This uses an f-string to create a query without escaping, resulting in an SQL injection:…
Recommended action: Upgrade to 9.1.10, 9.0.22 or 8.0.79 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details The exportgetRequestCountersWeb function is callable by any authenticated user and just passes its parameters directly to the database instance: https://github.com/DIRACGrid/DIRAC/blob/f7e0a3ac153315030fb3520e8ca747f013758967/src/DIRAC/RequestManagementSystem/Service/ReqManagerHandler.py#L270 If the groupingAttribute string is unrecognised, Request. is prepended to it and the result is passed into an eval() call: https://github.com/DIRACGrid/DIRAC/blob/f7e0a3ac153315030fb3520e8ca747f013758967/src/DIRAC/RequestManagementSystem/DB/RequestDB.py#L766-L776 By passing in a dunder string that is applicable to the Request object, it's possible to work back up to functions in the os module and trigger them to be called in the server context. There are…
Recommended action: Upgrade to 9.1.10, 9.0.22 or 8.0.79 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. Patches Has the problem been patched? What versions should users upgrade to? Workarounds Setting the X509USERPROXY environment variable to a path that is inside a directory that is only readable to the current user avoids the potential risk. After the file has been written it can be safely copied to the standard location (/tmp/x509upuNNNN). References
Recommended action: Upgrade to 8.0.41 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Any user could get a token that has been requested by another user/agent Patches The vulnerability is fixed in version 8.0.37. Workarounds None References
Recommended action: Upgrade to 8.0.37 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.