1. Introduction
The vulnerability “Ansible Tower 3.6.x =< 3.6.3 Archive Traversal Arbitrary File ..." is an arbitrary file overwrite issue in Ansible Tower versions 3.6.x and earlier, up to and including 3.6.3. This allows an attacker to potentially overwrite files on the system when extracting tar.gz archives. This could lead to a loss of confidentiality, integrity, or availability depending on the overwritten files. Systems running affected versions of Ansible Tower are at risk.
2. Technical Explanation
The vulnerability is caused by insufficient validation during archive extraction in Ansible Tower 3.6.x and earlier. An attacker can craft a malicious tar.gz archive containing filenames designed to traverse the file system, allowing them to overwrite arbitrary files on the server. The CVE identifier for this issue is CVE-2020-10691.
- Root cause: Missing input validation when extracting tar.gz archives.
- Exploit mechanism: An attacker uploads a specially crafted tar.gz archive that contains filenames with directory traversal characters (e.g., “../”). When extracted, these files can overwrite existing system files. For example, an archive could contain a file named “../../etc/passwd” which would attempt to overwrite the /etc/passwd file.
- Scope: Ansible Tower versions 3.6.x and earlier up to and including version 3.6.3 are affected.
3. Detection and Assessment
To confirm if a system is vulnerable, check the installed Ansible Tower version. A thorough method involves reviewing the application logs for archive extraction attempts.
- Quick checks: Run the following command to display the Ansible Tower version:
ansible-tower --version - Scanning: Nessus plugin ID 2020-B-0016-S can detect this vulnerability. This is an example only and may require updates.
- Logs and evidence: Check application logs for errors related to archive extraction or file overwrites. Specific log paths vary depending on the Ansible Tower configuration, but common locations include /var/log/ansible-tower/.
ansible-tower --version4. Solution / Remediation Steps
The solution is to contact the vendor for a fix. As of this writing, upgrading to a version later than 3.6.3 is recommended.
4.1 Preparation
- Ensure you have access to the vendor’s support channels for assistance and updates. A roll back plan involves restoring from the pre-change backup or snapshot.
- A change window may be required depending on your environment and service level agreements. Approval from system owners is recommended.
4.2 Implementation
- Step 1: Contact Red Hat support to obtain a patch or upgrade package for Ansible Tower.
- Step 2: Follow the vendor’s instructions to install the patch or upgrade Ansible Tower to a version greater than 3.6.3.
4.3 Config or Code Example
Before
# No specific configuration changes are required prior to patching, but ensure backups exist.After
# Verify the upgraded version after applying the patch: ansible-tower --version4.4 Security Practices Relevant to This Vulnerability
Several security practices can help mitigate this type of vulnerability. Least privilege reduces the impact if an attacker gains access. Input validation prevents malicious data from being processed. Patch cadence ensures systems are updated with the latest security fixes.
- Practice 1: Implement least privilege to limit the potential damage caused by a successful exploit.
- Practice 2: Enforce input validation on all user-supplied data, including file uploads.
4.5 Automation (Optional)
# No automation is provided as this requires vendor-supplied patches. Ansible can be used to automate the upgrade process once a patch package is available.5. Verification / Validation
Confirm the fix by verifying the upgraded version of Ansible Tower and re-testing for the vulnerability. Perform a smoke test to ensure core functionality remains operational.
- Post-fix check: Run
ansible-tower --versionand confirm the output shows a version greater than 3.6.3. - Re-test: Attempt to upload a malicious tar.gz archive (created for testing purposes) and verify that it is rejected or does not result in file overwrites.
- Smoke test: Verify that you can successfully run a simple Ansible playbook through the upgraded Tower instance.
- Monitoring: Monitor application logs for any errors related to archive extraction, indicating potential regressions.
ansible-tower --version6. Preventive Measures and Monitoring
Update security baselines to include the latest Ansible Tower version requirements. Implement checks in CI/CD pipelines to prevent vulnerable versions from being deployed. Establish a regular patch review cycle.
- Baselines: Update your security baseline or policy to require Ansible Tower versions greater than 3.6.3.
- Pipelines: Add static analysis (SAST) checks to your CI/CD pipeline to identify vulnerable components in Ansible playbooks and roles.
- Asset and patch process: Implement a regular patch review cycle, ideally within 30 days of vendor release.
7. Risks, Side Effects, and Roll Back
Upgrading Ansible Tower may introduce compatibility issues with existing playbooks or integrations. Always test in a non-production environment first. A roll back involves restoring from the pre-change backup or snapshot.
- Risk or side effect 2: Service downtime during upgrade process. Mitigation: Schedule upgrades during maintenance windows and communicate planned downtime to users.
8. References and Resources
- Vendor advisory or bulletin: https://access.redhat.com/security/cve/CVE-2020-10691
- NVD or CVE entry: /cve/CVE-2020-10691
- Product or platform documentation relevant to the fix: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-10691