Bug 1802124 (CVE-2020-1736) - CVE-2020-1736 ansible: atomic_move primitive sets permissive permissions
Summary: CVE-2020-1736 ansible: atomic_move primitive sets permissive permissions
Keywords:
Status: CLOSED WONTFIX
Alias: CVE-2020-1736
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1804394 1804395 1804396 1804397 1805331 1805332 1805364 1805365 1805366 1805367 1805499 1807876 1808313 1814770 1874346 1874348 1874350
Blocks: 1801714
TreeView+ depends on / blocked
 
Reported: 2020-02-12 12:18 UTC by Borja Tarraso
Modified: 2021-10-12 23:27 UTC (History)
31 users (show)

Fixed In Version: ansible-engine 2.8.15, ansible-engine 2.9.13
Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in Ansible Engine when a file is moved using atomic_move primitive as the file mode cannot be specified. This sets the destination files world-readable if the destination file does not exist and if the file exists, the file could be changed to have less restrictive permissions before the move. This issue affects only the newly created files and not existing ones. If the file already exists at the final destination, those permissions are retained. This could lead to the disclosure of sensitive data.
Clone Of:
Environment:
Last Closed: 2021-10-12 23:27:37 UTC
Embargoed:


Attachments (Terms of Use)

Description Borja Tarraso 2020-02-12 12:18:19 UTC
The atomic_move primitive is lacking moving files with a mode. This sets the destination files world-readable if the destination file does not exist and if the file exists could become with less restricted permissions before the move. This could lead in disclosing sensitive data.

Comment 2 Borja Tarraso 2020-02-17 12:56:40 UTC
Acknowledgments:

Name: Damien Aumaitre (Quarkslab), Nicolas Surbayrole (Quarkslab)

Comment 4 Salvatore Bonaccorso 2020-02-19 07:22:48 UTC
Any upstream reference for the issue available?

Comment 5 Borja Tarraso 2020-02-20 16:47:50 UTC
Created ansible tracking bugs for this issue:

Affects: epel-all [bug 1805332]
Affects: fedora-all [bug 1805331]

Comment 6 Borja Tarraso 2020-02-20 17:02:17 UTC
Hey Salvatore, I am working to provide additional information regarding this issue; more details as you requested, affected versions as well as upstream links in case we already have. Prioritising this for now, I will get back to you asap.

In reply to comment #4:
> Any upstream reference for the issue available?

Comment 9 Yadnyawalk Tale 2020-02-20 22:44:52 UTC
Red Hat CloudForms Management Engine 5.9 is in maintenance phase and we're no longer fixing "Low" severity CVEs.

Comment 13 Borja Tarraso 2020-02-27 10:24:11 UTC
Upstream fix: https://github.com/ansible/ansible/issues/67794

Comment 14 Borja Tarraso 2020-02-27 12:19:30 UTC
Created ansible tracking bugs for this issue:

Affects: openstack-rdo [bug 1807876]

Comment 16 Hardik Vyas 2020-03-18 16:13:02 UTC
Red Hat Gluster Storage and Red Hat Ceph Storage no longer maintains its own version of Ansible. The fix will be provided from core Ansible. But we still ship ansible separately for ceph ubuntu.

Comment 19 Yadnyawalk Tale 2020-05-11 09:40:43 UTC
CloudForms 5.11 do not use ansible-tower and 5.10 only using ansible-tower-venv-ansible atm. Closing this tracker.

Comment 24 Borja Tarraso 2020-08-20 07:19:27 UTC
Mitigation:

This issue can be mitigated by specifying the "mode" on the task. That just leaves a race condition in place where newly created files that specify a mode in the task briefly go from 666 - umask to the final mode. An alternative workaround if many new files are created and to avoid setting a specific mode for each file would be to set the "mode" to "preserve" value. That will maintain the permissions of the source file on the controller in the final file on the managed host.

Comment 29 Summer Long 2021-01-14 04:58:23 UTC
Statement:

Ansible Engine 2.8.14 and 2.9.12 as well as previous versions and all 2.7.x versions are affected.

Ansible Tower 3.6.5 and 3.7.2 as well as previous versions are affected.

In Red Hat OpenStack Platform, because the flaw has a lower impact,  ansible is not directly customer exposed, and the fix would require a substantial amount of development, no update will be provided at this time for the RHOSP ansible package.

Comment 42 Matt Davis 2021-10-12 23:27:37 UTC
Attempts were made to address this but ultimately removed as they caused more problems than they solved. Closing, as the products in question are no longer applying fixes for low severity CVEs.


Note You need to log in before you can comment on or make changes to this bug.