CVE-2024-7143
📋 TL;DR
This vulnerability in Pulp's role-based access control system incorrectly assigns object permissions when objects are created within tasks. Instead of granting permissions to the user who dispatched the task, it assigns them to the oldest user with any task permissions, potentially denying legitimate users access to their own created objects. This affects Pulp administrators and users who create objects through automated tasks.
💻 Affected Systems
- Pulp
- Red Hat Satellite (uses Pulp)
- Red Hat Insights (uses Pulp)
📦 What is this software?
Pulp by Pulpproject
Pulp by Pulpproject
⚠️ Risk & Real-World Impact
Worst Case
Critical data loss or operational disruption when users cannot access objects they created, potentially causing system-wide access control failures and privilege escalation scenarios.
Likely Case
Users lose access to objects they created through tasks, requiring administrative intervention to restore proper permissions and causing workflow disruptions.
If Mitigated
Minor inconvenience requiring manual permission adjustments for affected objects, with no data loss or unauthorized access.
🎯 Exploit Status
This is a logic flaw that triggers automatically under specific conditions rather than requiring active exploitation.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: Pulp 3.31.2 and 3.32.0
Vendor Advisory: https://access.redhat.com/errata/RHSA-2024:6765
Restart Required: Yes
Instructions:
1. Update Pulp to version 3.31.2 or 3.32.0. 2. For Red Hat Satellite: Apply RHSA-2024:6765. 3. Restart Pulp services. 4. Verify the fix by checking object permission assignments after task creation.
🔧 Temporary Workarounds
Disable task-based object creation
linuxAvoid creating RBAC-protected objects within tasks until patched
# Configure workflows to create objects outside of tasks
# Review and modify automation scripts that create objects in tasks
Manual permission remediation
linuxRegularly audit and correct object permissions for users affected by the bug
# Use pulp CLI or API to check object permissions
# pulp rpm repository list --fields name,pulp_created,pulp_last_updated
# Adjust permissions as needed for affected objects
🧯 If You Can't Patch
- Implement strict monitoring of object permission assignments and establish manual correction procedures
- Limit task creation permissions to minimize the number of users who could be affected as the 'oldest user'
🔍 How to Verify
Check if Vulnerable:
Check if objects created within tasks have permissions assigned to unexpected users (oldest task permission holder rather than task dispatcher). Review Pulp audit logs for permission assignment anomalies.Check Version:
pulp status | grep "Version" or rpm -q pulpcoreVerify Fix Applied:
After patching, create an object within a task and verify permissions are correctly assigned to the task dispatcher rather than the oldest user with task permissions.📡 Detection & Monitoring
Log Indicators:
- Unexpected permission assignments in Pulp audit logs
- User complaints about missing access to recently created objects
- Permission assignment logs showing incorrect user associations
Network Indicators:
- Increased API calls for permission adjustments
- Unusual pattern of object creation failures
SIEM Query:
source="pulp" AND ("permission denied" OR "access control" OR "AutoAddObjPermsMixin")🔗 References
- https://access.redhat.com/errata/RHSA-2024:6765
- https://access.redhat.com/security/cve/CVE-2024-7143
- https://bugzilla.redhat.com/show_bug.cgi?id=2300125
- https://github.com/pulp/pulpcore/blob/93f241f34c503da0fbac94bdba739feda2636e12/pulpcore/tasking/_util.py#L108
- https://github.com/pulp/pulpcore/blob/main/CHANGES.md
