Pulpcore: rbac permissions incorrectly assigned in tasks that create objects

A flaw was found in the Pulp package. When a role-based access control (RBAC) object in Pulp is set to assign permissions on its creation, it uses the `AutoAddObjPermsMixin` (typically the add_roles_for_object_creator method). This method finds the object creator by checking the current authenticated user. For objects that are created within a task, this current user is set by the first user with any permissions on the task object. This means the oldest user with model/domain-level task permissions will always be set as the current user of a task, even if they didn't dispatch the task. Therefore, all objects created in tasks will have their permissions assigned to this oldest user, and the creating user will receive nothing.

Pulp: Tokens stored in plaintext

The collection remote for pulp_ansible stores tokens in plaintext instead of using pulp's encrypted field and exposes them in read/write mode via the API () instead of marking it as write only.

pulp-consumer-client 2.4.0 through 2.6.3 does not check the server's TLS certificate signatures when retrieving the server's public key upon registration.

pulp: Potential leakage when generating new CA key in /tmp

server/bin/pulp-gen-ca-certificate in Pulp before 2.8.2 allows local users to read the generated private key.

pulp: Insecure creation of temporary directory when generating new CA key

Pulp before 2.8.3 creates a temporary directory during CA key generation in an insecure manner.

pulp: Node certificate containing private key stored in world-readable file

The Node certificate in Pulp before 2.8.3 contains the private key, and is stored in a world-readable file in the "/etc/pki/pulp/nodes/" directory, which allows local users to gain access to sensitive data.

pulp: Insecure temporary file used when generating certificate for Pulp Nodes

The pulp-gen-nodes-certificate script in Pulp before 2.8.3 allows local users to leak the keys or write to arbitrary files via a symlink attack.

pulp: distributed with CA from public code repository

Pulp before 2.3.0 uses the same the same certificate authority key and certificate for all installations.

pulp: Agent certificate containing private key is stored in world-readable file

client/consumer/cli.py in Pulp before 2.8.3 writes consumer private keys to etc/pki/pulp/consumer/consumer-cert.pem as world-readable, which allows remote authenticated users to obtain the consumer private keys and escalate privileges by reading /etc/pki/pulp/consumer/consumer-cert, and authenticating as a consumer user.

pulp: Leakage of CA key in pulp-qpid-ssl-cfg

The pulp-qpid-ssl-cfg script in Pulp before 2.8.5 allows local users to obtain the CA key.

pulp: Unsafe use of bash $RANDOM for NSS DB password and seed

Pulp before 2.8.5 uses bash's $RANDOM in an unsafe way to generate passwords.

pulp: Race condition when generating RSA keys for authenticating messages between server and consumers

pulp.spec in the installation process for Pulp 2.8.3 generates the RSA key pairs used to validate messages between the pulp server and pulp consumers in a directory that is world-readable before later modifying the permissions, which might allow local users to read the generated RSA keys via reading the key files while the installation process is running.

Satellite6: python pickle() processing problem in pulp

The Qpid server on Red Hat Satellite 6 does not properly restrict message types, which allows remote authenticated users with administrative access on a managed content host to execute arbitrary code via a crafted message, related to a pickle processing problem in pulp.

pulp: sensitive credentials revealed through the API

In Pulp before version 2.16.2, secrets are passed into override_config when triggering a task and then become readable to all users with read access on the distributor/importer. An attacker with API access can then view these secrets.

pulp: Improper path parsing leads to overwriting of iso repositories

pulp 2.16.x and possibly older is vulnerable to an improper path parsing. A malicious user or a malicious iso feed repository can write to locations accessible to the 'apache' user. This may lead to overwrite of published content on other iso repositories.