A path traversal vulnerability was found in pulpcore's relativepathvalidator (pulpcore/app/serializers/fields.py). The validator only checks os.path.isabs() to block paths starting with "/", but does not block "../" directory traversal sequences anywhere in the path.

When a user creates content via POST /api/v3/content/file/files/ with a crafted relativepath (e.g., "looking/normal/../../../../etc/cron.d/backdoor"), the value passes validation and is stored in ContentArtifact.relativepath. During FilesystemExport (pulpcore/app/tasks/export.py), os.path.join(path, relativepath) resolves outside the export directory, and the raw artifact content (fully attacker-controlled) is written to the escaped path.

The process runs as the "pulp" system user. File permission bits cannot be set by the attacker. FilesystemExport is only accessible to admin-level users (SSL cert auth in Satellite, admin role in RBAC deployments).

Affected: pulpcore (all versions through current HEAD 3.110.0.dev) Fix: Not yet available (coordinating with upstream) Reporter: Martin Brodeur (independent security researcher) PSIRT Ticket: PSIRTSUPT-7617

When an RBAC object in Pulp is set to assign perms on its creation it uses the AutoAddObjPermsMixin, typically the method addrolesforobjectcreator. 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 perms on the task object. This means the oldest user with model/domain-level task perms will always be set to the current user of a task even if they didn't dispatch the task. Thus all objects created in tasks will have their permissions assigned to this oldest user, and the creating user will receive nothing.

A flaw was found in pulp 2.16.x and possibly older. 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.

It was found that spec file generating RSA keys, used for authenticating messages between server and consumers, as post installation step does this in world-readable directories for a brief moment.

Vulnerable code:

https://github.com/pulp/pulp/blob/master/pulp.spec#L473-L486 https://github.com/pulp/pulp/blob/master/pulp.spec#L894-L903

It was found that newly generated CA keys by running pulp-gen-ca-certificate (which is run by spec file when pulp is installed) script are insufficiently protected against reading by other users for the time the script runs.

Vulnerable code:

https://github.com/pulp/pulp/blob/2.8.0/server/bin/pulp-gen-ca-certificate

It is reported by Austin Macdonald that pulp fails to properly remove existing permissions when an object is deleted (e.g. a user account), if an object with the same name is later created it will inherit the previous permissions leading to a potential privilege escalation. Please note that due to the manner in which pulp is used in Satellite6 it is not vulnerable.

Hi, From [2]: #### CVE-2024-7923: Authentication bypass in Pulpcore An authentication bypass vulnerability has been identified in Pulpcore when deployed by the Foreman Installer with Gunicorn versions prior to 22.0. This issue arises from the way Apache is configured to do certificate authentication and pass this information to the Gunicorn backend, without unsetting all headers coming from a possibly malicious client. Affects Katello 4.0.0 and higher Fix released in Foreman 3.10.1, 3.11.2, 3.12.0 GitHub PR puppet-pulpcore#357 #### CVE-2024-7012: Authentication bypass in Foreman An authentication bypass vulnerability has been identified in Foreman when deployed by the Foreman Installer with External Authentication. This issue arises from the way Apache is configured to do certificate authentication and pass this information to the Puma backend, without unsetting all headers coming from a possibly malicious client. Affects Foreman 2.2.0 and higher Fix released in Foreman 3.10.1, 3.11.2, 3.12.0 GitHub PR puppet-foreman#1181 Further References: [1] https://community.theforeman.org/t/foreman-3-11-2-is-now-available/39370 [2] https://theforeman.org/security.html#2024-7923 [3] https://access.redhat.com/security/cve/CVE-2024-7012 [4] https://access.redhat.com/security/cve/CVE-2024-7923 https://projects.theforeman.org/issues/37786?tab=changesets https://projects.theforeman.org/issues/37787?tab=changesets

Kind regards, Christian