CVE-2021-3447: Red Hat Ansible Information Disclosure Flaw

CVE-2021-3447 Overview

A flaw was found in several Ansible modules where parameters containing credentials, such as secrets, were being logged in plain-text on managed nodes, as well as being made visible on the controller node when run in verbose mode. These parameters were not protected by the no_log feature that Ansible provides to mask sensitive data. An attacker can take advantage of this information to steal those credentials, provided they have access to the log files containing them. The highest threat from this vulnerability is to data confidentiality.

Critical Impact

Credentials and secrets logged in plain-text can be harvested by attackers with local access to log files on managed nodes or controller systems, leading to potential credential theft and lateral movement.

Affected Products

• Red Hat Ansible Automation Platform (versions before 1.2.2)
• Red Hat Ansible Tower (versions before 3.8.2)
• Fedora 32, 33, and 34

Discovery Timeline

• 2021-04-01 - CVE-2021-3447 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2021-3447

Vulnerability Analysis

This vulnerability is classified as CWE-532 (Insertion of Sensitive Information into Log File). The fundamental issue lies in how several Ansible modules handle credential parameters during task execution. When Ansible playbooks are executed, especially in verbose mode, the affected modules fail to properly sanitize output containing sensitive information such as passwords, API keys, tokens, and other secrets.

Ansible provides a no_log feature specifically designed to prevent sensitive data from appearing in logs. However, certain modules were not properly implementing this protection, resulting in credentials being written to log files on managed nodes and displayed on the controller node's output. This creates a significant risk in environments where multiple administrators have access to systems running Ansible, or where log files are aggregated to centralized logging systems.

The vulnerability requires local access to exploit, meaning an attacker would need access to the log files on either managed nodes or the Ansible controller. While this limits the attack surface, organizations with shared infrastructure or insufficient access controls on log storage systems are particularly at risk.

Root Cause

The root cause is the failure of several Ansible modules to properly implement the no_log directive for parameters containing sensitive information. This oversight in the module development process allowed credential parameters to bypass the logging sanitization mechanism, resulting in plain-text credential exposure in system logs and verbose output.

Attack Vector

The attack requires local access to systems where Ansible logs are stored. An attacker with read access to log files on managed nodes or the Ansible controller node can extract credentials that were logged in plain-text. This is particularly dangerous in scenarios where:

• Logs are shipped to centralized logging systems accessible by multiple users
• Managed nodes have shared access among different teams
• Ansible is run in verbose mode for debugging purposes
• Log retention policies keep sensitive data accessible for extended periods

The vulnerability is exploited by simply reading log files that contain the exposed credentials, making it trivial to harvest once access to the logs is obtained.

Detection Methods for CVE-2021-3447

Indicators of Compromise

• Unexpected access to Ansible log files on managed nodes or controller systems
• Log file access patterns indicating credential harvesting (bulk reads of Ansible logs)
• Use of harvested credentials from unexpected source systems or at unusual times
• Unauthorized access to systems using credentials that were only used in Ansible playbooks

Detection Strategies

• Monitor file access events on Ansible log directories (/var/log/ansible/, .ansible/ user directories)
• Implement log integrity monitoring to detect unauthorized log file access
• Audit authentication events for credentials that appear in Ansible playbook tasks
• Deploy SentinelOne agents on Ansible controllers and managed nodes to detect suspicious file access patterns

Monitoring Recommendations

• Enable file integrity monitoring on systems running Ansible to detect unauthorized log access
• Configure alerts for bulk log file reads or copies from Ansible-related directories
• Implement centralized logging with access controls that limit who can view raw log data
• Review Ansible execution logs regularly for unintentionally exposed sensitive parameters

How to Mitigate CVE-2021-3447

Immediate Actions Required

• Upgrade Red Hat Ansible Automation Platform to version 1.2.2 or later
• Upgrade Red Hat Ansible Tower to version 3.8.2 or later
• Review and rotate any credentials that may have been exposed in logs
• Audit existing log files for credential exposure and securely delete affected logs
• Restrict access to Ansible log files using appropriate file permissions

Patch Information

Red Hat has released security updates addressing this vulnerability. The patched versions are Red Hat Ansible Automation Platform 1.2.2 and Red Hat Ansible Tower 3.8.2. For detailed information, refer to the Red Hat Bug Report #1939349. Fedora users should apply the updates available through the Fedora Package Announcements. Debian users can reference the Debian LTS Announcement for applicable updates.

Workarounds

• Explicitly add no_log: true to all tasks that handle sensitive parameters as a defensive measure
• Avoid running Ansible in verbose mode (-v, -vv, -vvv) in production environments
• Implement strict file permissions on log directories to limit read access
• Consider implementing log scrubbing solutions to remove credentials before storage
• Use Ansible Vault for credential management to minimize direct credential handling in playbooks

# Example: Securing Ansible log directories
chmod 700 /var/log/ansible
chmod 600 /var/log/ansible/*

# Ensure tasks handling credentials use no_log
# In your playbook, add no_log directive:
# - name: Authenticate to service
#   uri:
#     url: "https://api.example.com/auth"
#     user: "{{ api_user }}"
#     password: "{{ api_password }}"
#   no_log: true