Bug 1403228 - ansible: Variables from vault are being output to console/log when using with_items
Summary: ansible: Variables from vault are being output to console/log when using with...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
: 1743217 (view as bug list)
Depends On: 1403229 1403230 1403231 1403232
Blocks: 1403234
TreeView+ depends on / blocked
 
Reported: 2016-12-09 13:18 UTC by Adam Mariš
Modified: 2020-02-14 18:17 UTC (History)
54 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-23 17:58:47 UTC

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Description Adam Mariš 2016-12-09 13:18:06 UTC 
It was found that variables from vault are being printed to the console/log during the ansible run when using with_items, potentially exposing security-sensitive data.

Upstream bug:

https://github.com/ansible/ansible/issues/14646
Comment 1 Adam Mariš 2016-12-09 13:19:36 UTC 
Created ansible1.9 tracking bugs for this issue:

Affects: fedora-all [bug 1403230]
Affects: epel-all [bug 1403232]
Comment 2 Adam Mariš 2016-12-09 13:20:01 UTC 
Created ansible tracking bugs for this issue:

Affects: fedora-all [bug 1403229]
Affects: epel-all [bug 1403231]
Comment 4 Kurt Seifried 2016-12-23 17:58:47 UTC 
> From: Kurt Seifried
> Ok just to confirm once you set this in the playbook (no_log) it can only
> be overridden by the env var correct?
> 
> "Note that the use of the no_log attribute does not prevent data from
> being shown when debugging Ansible itself via the ANSIBLE_DEBUG
> environment variable."
> 
> however both of these are essentially under administrative control on the
> ansible server, by users that would also have access to the ansible vault,
> correct?

Correct - passing ANSIBLE_DEBUG implies you're running the playbook, and
to run the playbook, you'd have access to the vault file and would need
the vault password to decrypt it anyway.

Hide quoted text
> If so there is no trust boundary violation, so this is not a security
> vulnerability, so no CVE/etc. It could be seen potentially as something
> to harden, but that would be at your discretion essentially (and in this
> case it appears to not even be something that should be hardened as it
> already has been via no_log essentially).
> 
> If confirmed I'll close it out on my side.


Thanks!

Bill
Comment 5 Borja Tarraso 2019-09-10 11:47:55 UTC 
*** Bug 1743217 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.