{
  "threat_severity" : "Moderate",
  "public_date" : "2020-02-18T00:00:00Z",
  "bugzilla" : {
    "description" : "ansible: insecure temporary directory when running become_user from become directive",
    "id" : "1801735",
    "url" : "https://bugzilla.redhat.com/show_bug.cgi?id=1801735"
  },
  "cvss3" : {
    "cvss3_base_score" : "5.0",
    "cvss3_scoring_vector" : "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:L",
    "status" : "verified"
  },
  "cwe" : "CWE-377",
  "details" : [ "A race condition flaw was found in Ansible Engine 2.7.17 and prior, 2.8.9 and prior, 2.9.6 and prior when running a playbook with an unprivileged become user. When Ansible needs to run a module with become user, the temporary directory is created in /var/tmp. This directory is created with \"umask 77 && mkdir -p <dir>\"; this operation does not fail if the directory already exists and is owned by another user. An attacker could take advantage to gain control of the become user as the target directory can be retrieved by iterating '/proc/<pid>/cmdline'.", "A race condition flaw was found in Ansible Engine when running a playbook with an unprivileged become user. When Ansible needs to run a module with become user, the temporary directory is created in /var/tmp. This directory is created with \"umask 77 && mkdir -p <dir>\"; this operation does not fail if the directory already exists and is owned by another user. An attacker could take advantage to gain control of the become user as the target directory can be retrieved by iterating '/proc/<pid>/cmdline'." ],
  "statement" : "Ansible Engine 2.7.16, 2.8.10, and 2.9.6 as well as previous versions are affected.\nAnsible Tower 3.4.5, 3.5.5 and 3.6.3 as well as previous versions are affected.\nIn 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.",
  "acknowledgement" : "Red Hat would like to thank Damien Aumaitre (Quarkslab) and Nicolas Surbayrole (Quarkslab) for reporting this issue.",
  "affected_release" : [ {
    "product_name" : "Red Hat Ansible Engine 2.7 for RHEL 7",
    "release_date" : "2020-04-22T00:00:00Z",
    "advisory" : "RHSA-2020:1544",
    "cpe" : "cpe:/a:redhat:ansible_engine:2.7::el7",
    "package" : "ansible-0:2.7.17-1.el7ae"
  }, {
    "product_name" : "Red Hat Ansible Engine 2.8 for RHEL 7",
    "release_date" : "2020-04-22T00:00:00Z",
    "advisory" : "RHSA-2020:1543",
    "cpe" : "cpe:/a:redhat:ansible_engine:2.8::el7",
    "package" : "ansible-0:2.8.11-1.el7ae"
  }, {
    "product_name" : "Red Hat Ansible Engine 2.8 for RHEL 8",
    "release_date" : "2020-04-22T00:00:00Z",
    "advisory" : "RHSA-2020:1543",
    "cpe" : "cpe:/a:redhat:ansible_engine:2.8::el8",
    "package" : "ansible-0:2.8.11-1.el8ae"
  }, {
    "product_name" : "Red Hat Ansible Engine 2.9 for RHEL 7",
    "release_date" : "2020-04-22T00:00:00Z",
    "advisory" : "RHSA-2020:1541",
    "cpe" : "cpe:/a:redhat:ansible_engine:2.9::el7",
    "package" : "ansible-0:2.9.7-1.el7ae"
  }, {
    "product_name" : "Red Hat Ansible Engine 2.9 for RHEL 8",
    "release_date" : "2020-04-22T00:00:00Z",
    "advisory" : "RHSA-2020:1541",
    "cpe" : "cpe:/a:redhat:ansible_engine:2.9::el8",
    "package" : "ansible-0:2.9.7-1.el8ae"
  }, {
    "product_name" : "Red Hat Ansible Engine 2 for RHEL 7",
    "release_date" : "2020-04-22T00:00:00Z",
    "advisory" : "RHSA-2020:1542",
    "cpe" : "cpe:/a:redhat:ansible_engine:2::el7",
    "package" : "ansible-0:2.9.7-1.el7ae"
  }, {
    "product_name" : "Red Hat Ansible Engine 2 for RHEL 8",
    "release_date" : "2020-04-22T00:00:00Z",
    "advisory" : "RHSA-2020:1542",
    "cpe" : "cpe:/a:redhat:ansible_engine:2::el8",
    "package" : "ansible-0:2.9.7-1.el8ae"
  } ],
  "package_state" : [ {
    "product_name" : "CloudForms Management Engine 5",
    "fix_state" : "Not affected",
    "package_name" : "ansible-tower",
    "cpe" : "cpe:/a:redhat:cloudforms_managementengine:5"
  }, {
    "product_name" : "Red Hat Ansible Tower 3",
    "fix_state" : "Affected",
    "package_name" : "ansible",
    "cpe" : "cpe:/a:redhat:ansible_tower:3"
  }, {
    "product_name" : "Red Hat Ceph Storage 2",
    "fix_state" : "Out of support scope",
    "package_name" : "ansible",
    "cpe" : "cpe:/a:redhat:ceph_storage:2"
  }, {
    "product_name" : "Red Hat Ceph Storage 3",
    "fix_state" : "Will not fix",
    "package_name" : "ansible",
    "cpe" : "cpe:/a:redhat:ceph_storage:3"
  }, {
    "product_name" : "Red Hat OpenStack Platform 10 (Newton)",
    "fix_state" : "Out of support scope",
    "package_name" : "ansible",
    "cpe" : "cpe:/a:redhat:openstack:10"
  }, {
    "product_name" : "Red Hat OpenStack Platform 13 (Queens)",
    "fix_state" : "Will not fix",
    "package_name" : "ansible",
    "cpe" : "cpe:/a:redhat:openstack:13"
  }, {
    "product_name" : "Red Hat Storage 3",
    "fix_state" : "Will not fix",
    "package_name" : "ansible",
    "cpe" : "cpe:/a:redhat:storage:3"
  } ],
  "references" : [ "https://www.cve.org/CVERecord?id=CVE-2020-1733\nhttps://nvd.nist.gov/vuln/detail/CVE-2020-1733" ],
  "name" : "CVE-2020-1733",
  "mitigation" : {
    "value" : "This issue can be mitigated by mounting the proc filesystem with hidepid=2 option (https://www.kernel.org/doc/Documentation/filesystems/proc.txt). This way only the user used by Ansible will be able to perform the attack as users on the system will be able to access only their processes /proc/$PID/ directories.\nAlso note that mounting proc filesystem with hidepid=2 might require re-mounting it on unpatched kernels, due to a kernel bug (see https://unix.stackexchange.com/questions/584054/why-procfs-mount-option-only-working-on-remount), there will be hidepid=3 in the future (https://patchwork.kernel.org/patch/11310217/).",
    "lang" : "en:us"
  },
  "csaw" : false
}