REDHAT-BUG-2524651: Medium severity community.general/ansible/ipa_getkeytab vulnerability
community.general's ipagetkeytab module (plugins/modules/ipagetkeytab.py) declares its bindpw argument WITHOUT nolog:
binddn=dict(type="str"), bindpw=dict(type="str"), # missing nolog password=dict(type="str", nolog=True), # sibling has it
Because the value is neither flagged with nolog nor caught by ansible-core's name-based redaction heuristic, the IPA simple-bind password is disclosed through several channels.
Exposure vectors ---------------- 1. Log disclosure (CWE-532): the value appears in cleartext in the target host's journal/syslog "Invoked with" line, in the module's return values / -v output, and in Automation Controller / AWX job output. 2. Process-list disclosure (CWE-214): the module passes the password to the child helper as ipa-getkeytab ... --bindpw <cleartext> ... (bindpw=cmdrunnerfmt.asoptval("--bindpw")), so it is visible in ps / /proc/<pid>/cmdline to local users during execution. This vector is the child process's own argv and is NOT remediated by nolog. 3. Contributing cleartext storage (CWE-312).
Why automatic redaction does not apply -------------------------------------- ansible-core's name-based safety net is PASSWORDMATCH in lib/ansible/moduleutils/basic.py (not parameters.py). Its regex requires a literal "pass" substring:
^(?:.+[-\s])?pass(?:[-\s]?(?:word|phrase|wrd|wd)?)(?:[-\s].+)?$
"bindpw" / "bindpw" contain no "pass" substring, so the pattern does not match: no warning and no auto-redaction. Even when PASSWORDMATCH does match a name, it only substitutes 'NOTLOGGINGPASSWORD' in the "Invoked with" line and emits a warning — it does not add the value to nologvalues, so return values and other logging remain unredacted. Explicit nolog=True in the argument spec is therefore the required fix.
Affected Software
Event History
Frequently Asked Questions
Who can obtain the IPA simple-bind password through this issue?
Users or systems able to read target-host journal or syslog records, Ansible verbose or module return output, or Automation Controller/AWX job output may see the password. Local users who can inspect process listings or /proc/<pid>/cmdline during execution may also obtain it from the ipa-getkeytab helper process arguments.
How can I determine whether credentials may already have been exposed?
Review target-host journal/syslog entries for the module's "Invoked with" output, as well as Ansible verbose output, module return values, and Automation Controller/AWX job output from runs using bind_pw. Also assess whether local users could have observed the ipa-getkeytab process command line while those jobs were executing.
Would marking bind_pw as no_log eliminate every exposure path?
No. Marking the argument no_log addresses Ansible-side output and logging disclosure, but it does not protect the password passed to the child helper as --bindpw <cleartext>, which can remain visible through process arguments during execution.