As of today, upstream has not fixed this yet, as the proposed patch breaks other code.
IMHO this is a no-DSA bug which we can fix when upstream fixes it, because the following conditions need to be met: - The user has configured umask 000 for the ansible user on the target (which is not default on Debian) - the ansible task creating the file does not define file permissions In this case the file is created with 0666 permissions, which I'd call "expected behaviour", just as "umask 000; touch myfile" will create a world-readable file. Simple workarounds are either defining a sane umask, or setting the permissions explicitely, which is recommended anyway. On Sat, 01 Aug 2020 13:44:43 +0200 Salvatore Bonaccorso <car...@debian.org> wrote: > Source: ansible > Version: 2.9.9+dfsg-1 > Severity: important > Tags: security upstream > Forwarded: https://github.com/ansible/ansible/issues/67794 > X-Debbugs-Cc: Debian Security Team <t...@security.debian.org> > > Hi, > > The following vulnerability was published for ansible. > > CVE-2020-1736[0]: > | 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 could lead to the > | disclosure of sensitive data. All versions in 2.7.x, 2.8.x and 2.9.x > | branches are believed to be vulnerable. > > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2020-1736 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1736 > [1] https://github.com/ansible/ansible/issues/67794 > > Please adjust the affected versions in the BTS as needed. > > Regards, > Salvatore > >
