USN-4589-1 fixed a vulnerability in containerd. This update provides
the corresponding update for docker.io.
Original advisory details:
It was discovered that containerd could be made to expose sensitive
information when processing URLs in container image manifests. A
remote attacker could use this to trick the user and obtain the
user's registry credentials.
{"github": [{"lastseen": "2022-04-19T19:29:35", "description": "## Impact\n\nIf a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a \u201cforeign layer\u201d), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers.\n\nIf an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account.\n\nThe default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it.\n\nThis vulnerability has been rated by the containerd maintainers as medium, with a CVSS score of 6.1 and a vector string of CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N.\n\n## Patches\n\nThis vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected.\n\n## Workarounds\n\nIf you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources. Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected.\n\n## Credits\n\nThe containerd maintainers would like to thank Brad Geesaman, Josh Larsen, Ian Coldwater, Duffie Cooley, and Rory McCune for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/master/SECURITY.md).", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "baseScore": 6.1, "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 4.0}, "published": "2022-02-11T23:27:39", "type": "github", "title": "containerd v1.2.x can be coerced into leaking credentials during image pull", "bulletinFamily": "software", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 2.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2022-04-19T19:02:37", "id": "GHSA-742W-89GC-8M9C", "href": "https://github.com/advisories/GHSA-742w-89gc-8m9c", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}], "nessus": [{"lastseen": "2021-08-19T12:11:35", "description": "The remote Oracle Linux 7 host has a package installed that is affected by a vulnerability as referenced in the ELSA-2020-5906 advisory.\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected. (CVE-2020-15157)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.", "cvss3": {"score": 6.1, "vector": "CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N"}, "published": "2020-11-03T00:00:00", "type": "nessus", "title": "Oracle Linux 7 : containerd (ELSA-2020-5906)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157"], "modified": "2021-03-18T00:00:00", "cpe": ["cpe:/o:oracle:linux:7", "p-cpe:/a:oracle:linux:containerd"], "id": "ORACLELINUX_ELSA-2020-5906.NASL", "href": "https://www.tenable.com/plugins/nessus/142222", "sourceData": "##\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were\n# extracted from Oracle Linux Security Advisory ELSA-2020-5906.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(142222);\n script_version(\"1.4\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/03/18\");\n\n script_cve_id(\"CVE-2020-15157\");\n\n script_name(english:\"Oracle Linux 7 : containerd (ELSA-2020-5906)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote Oracle Linux host is missing a security update.\");\n script_set_attribute(attribute:\"description\", value:\n\"The remote Oracle Linux 7 host has a package installed that is affected by a vulnerability as referenced in the\nELSA-2020-5906 advisory.\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking\n vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format\n includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the\n default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or\n later, the default containerd resolver will provide its authentication credentials if the server where the\n URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker\n publishes a public image with a manifest that directs one of the layers to be fetched from a web server\n they control and they trick a user or system into pulling the image, they can obtain the credentials used\n for pulling that image. In some cases, this may be the user's username and password for the registry. In\n other cases, this may be the credentials attached to the cloud virtual instance which can grant access to\n other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin\n (which can be used by Kubernetes), the ctr development tool, and other client programs that have\n explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and\n later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using\n cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker)\n are not affected. (CVE-2020-15157)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version\nnumber.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://linux.oracle.com/errata/ELSA-2020-5906.html\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected containerd package.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:H/Au:N/C:P/I:N/A:N\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2020-15157\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2020/11/02\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2020/11/03\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:oracle:linux:7\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:oracle:linux:containerd\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Oracle Linux Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2020-2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/OracleLinux\", \"Host/RedHat/release\", \"Host/RedHat/rpm-list\", \"Host/local_checks_enabled\");\n\n exit(0);\n}\n\n\ninclude('audit.inc');\ninclude('global_settings.inc');\ninclude('rpm.inc');\n\nif (!get_kb_item('Host/local_checks_enabled')) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nif (!get_kb_item('Host/OracleLinux')) audit(AUDIT_OS_NOT, 'Oracle Linux');\nrelease = get_kb_item(\"Host/RedHat/release\");\nif (isnull(release) || !pregmatch(pattern: \"Oracle (?:Linux Server|Enterprise Linux)\", string:release)) audit(AUDIT_OS_NOT, 'Oracle Linux');\nos_ver = pregmatch(pattern: \"Oracle (?:Linux Server|Enterprise Linux) .*release ([0-9]+(\\.[0-9]+)?)\", string:release);\nif (isnull(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, 'Oracle Linux');\nos_ver = os_ver[1];\nif (! preg(pattern:\"^7([^0-9]|$)\", string:os_ver)) audit(AUDIT_OS_NOT, 'Oracle Linux 7', 'Oracle Linux ' + os_ver);\n\nif (!get_kb_item('Host/RedHat/rpm-list')) audit(AUDIT_PACKAGE_LIST_MISSING);\n\ncpu = get_kb_item('Host/cpu');\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif ('x86_64' >!< cpu && cpu !~ \"^i[3-6]86$\" && 'aarch64' >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'Oracle Linux', cpu);\nif ('x86_64' >!< cpu) audit(AUDIT_ARCH_NOT, 'x86_64', cpu);\n\npkgs = [\n {'reference':'containerd-1.2.14-1.0.1.el7', 'cpu':'x86_64', 'release':'7'}\n];\n\nflag = 0;\nforeach package_array ( pkgs ) {\n reference = NULL;\n release = NULL;\n sp = NULL;\n cpu = NULL;\n el_string = NULL;\n rpm_spec_vers_cmp = NULL;\n epoch = NULL;\n allowmaj = NULL;\n rpm_prefix = NULL;\n if (!empty_or_null(package_array['reference'])) reference = package_array['reference'];\n if (!empty_or_null(package_array['release'])) release = 'EL' + package_array['release'];\n if (!empty_or_null(package_array['sp'])) sp = package_array['sp'];\n if (!empty_or_null(package_array['cpu'])) cpu = package_array['cpu'];\n if (!empty_or_null(package_array['el_string'])) el_string = package_array['el_string'];\n if (!empty_or_null(package_array['rpm_spec_vers_cmp'])) rpm_spec_vers_cmp = package_array['rpm_spec_vers_cmp'];\n if (!empty_or_null(package_array['epoch'])) epoch = package_array['epoch'];\n if (!empty_or_null(package_array['allowmaj'])) allowmaj = package_array['allowmaj'];\n if (!empty_or_null(package_array['rpm_prefix'])) rpm_prefix = package_array['rpm_prefix'];\n if (reference && release) {\n if (rpm_prefix) {\n if (rpm_exists(release:release, rpm:rpm_prefix) && rpm_check(release:release, sp:sp, cpu:cpu, reference:reference, epoch:epoch, el_string:el_string, rpm_spec_vers_cmp:rpm_spec_vers_cmp, allowmaj:allowmaj)) flag++;\n } else {\n if (rpm_check(release:release, sp:sp, cpu:cpu, reference:reference, epoch:epoch, el_string:el_string, rpm_spec_vers_cmp:rpm_spec_vers_cmp, allowmaj:allowmaj)) flag++;\n }\n }\n}\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_NOTE,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, 'containerd');\n}", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}, {"lastseen": "2021-08-19T12:12:01", "description": "The remote Ubuntu 16.04 LTS host has a package installed that is affected by a vulnerability as referenced in the USN-4589-1 advisory. Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.", "cvss3": {"score": 6.1, "vector": "CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N"}, "published": "2020-10-16T00:00:00", "type": "nessus", "title": "Ubuntu 16.04 LTS : containerd vulnerability (USN-4589-1)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157"], "modified": "2021-03-18T00:00:00", "cpe": ["cpe:/o:canonical:ubuntu_linux:16.04:-:lts", "p-cpe:/a:canonical:ubuntu_linux:containerd"], "id": "UBUNTU_USN-4589-1.NASL", "href": "https://www.tenable.com/plugins/nessus/141479", "sourceData": "##\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were\n# extracted from Ubuntu Security Notice USN-4589-1. The text\n# itself is copyright (C) Canonical, Inc. See\n# <http://www.ubuntu.com/usn/>. Ubuntu(R) is a registered\n# trademark of Canonical, Inc.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(141479);\n script_version(\"1.4\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/03/18\");\n\n script_cve_id(\"CVE-2020-15157\");\n script_xref(name:\"USN\", value:\"4589-1\");\n\n script_name(english:\"Ubuntu 16.04 LTS : containerd vulnerability (USN-4589-1)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote Ubuntu host is missing a security update.\");\n script_set_attribute(attribute:\"description\", value:\n\"The remote Ubuntu 16.04 LTS host has a package installed that is affected by a vulnerability as referenced in the\nUSN-4589-1 advisory. Note that Nessus has not tested for this issue but has instead relied only on the application's\nself-reported version number.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://ubuntu.com/security/notices/USN-4589-1\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected containerd package.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:H/Au:N/C:P/I:N/A:N\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2020-15157\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/15\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2020/10/15\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2020/10/16\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:canonical:ubuntu_linux:16.04:-:lts\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:canonical:ubuntu_linux:containerd\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Ubuntu Local Security Checks\");\n\n script_copyright(english:\"Ubuntu Security Notice (C) 2020-2021 Canonical, Inc. / NASL script (C) 2020-2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/cpu\", \"Host/Ubuntu\", \"Host/Ubuntu/release\", \"Host/Debian/dpkg-l\");\n\n exit(0);\n}\n\ninclude('audit.inc');\ninclude('ubuntu.inc');\ninclude('misc_func.inc');\n\nif ( ! get_kb_item('Host/local_checks_enabled') ) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nrelease = get_kb_item('Host/Ubuntu/release');\nif ( isnull(release) ) audit(AUDIT_OS_NOT, 'Ubuntu');\nrelease = chomp(release);\nif (! preg(pattern:\"^(16\\.04)$\", string:release)) audit(AUDIT_OS_NOT, 'Ubuntu 16.04', 'Ubuntu ' + release);\nif ( ! get_kb_item('Host/Debian/dpkg-l') ) audit(AUDIT_PACKAGE_LIST_MISSING);\n\ncpu = get_kb_item('Host/cpu');\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif ('x86_64' >!< cpu && cpu !~ \"^i[3-6]86$\") audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'Ubuntu', cpu);\n\n\npkgs = [\n {'osver': '16.04', 'pkgname': 'containerd', 'pkgver': '1.2.6-0ubuntu1~16.04.4'}\n];\n\nflag = 0;\nforeach package_array ( pkgs ) {\n osver = NULL;\n pkgname = NULL;\n pkgver = NULL;\n if (!empty_or_null(package_array['osver'])) osver = package_array['osver'];\n if (!empty_or_null(package_array['pkgname'])) pkgname = package_array['pkgname'];\n if (!empty_or_null(package_array['pkgver'])) pkgver = package_array['pkgver'];\n if (osver && pkgname && pkgver) {\n if (ubuntu_check(osver:osver, pkgname:pkgname, pkgver:pkgver)) flag++;\n }\n}\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_NOTE,\n extra : ubuntu_report_get()\n );\n exit(0);\n}\nelse\n{\n tested = ubuntu_pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, 'containerd');\n}", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}, {"lastseen": "2021-08-19T12:11:47", "description": "The remote Oracle Linux 7 host has packages installed that are affected by a vulnerability as referenced in the ELSA-2020-5900 advisory.\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected. (CVE-2020-15157)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.", "cvss3": {"score": 6.1, "vector": "CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N"}, "published": "2020-10-28T00:00:00", "type": "nessus", "title": "Oracle Linux 7 : docker-engine / docker-cli (ELSA-2020-5900)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157"], "modified": "2021-03-18T00:00:00", "cpe": ["cpe:/o:oracle:linux:7", "p-cpe:/a:oracle:linux:docker-cli", "p-cpe:/a:oracle:linux:docker-engine"], "id": "ORACLELINUX_ELSA-2020-5900.NASL", "href": "https://www.tenable.com/plugins/nessus/142024", "sourceData": "##\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were\n# extracted from Oracle Linux Security Advisory ELSA-2020-5900.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(142024);\n script_version(\"1.5\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/03/18\");\n\n script_cve_id(\"CVE-2020-15157\");\n\n script_name(english:\"Oracle Linux 7 : docker-engine / docker-cli (ELSA-2020-5900)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote Oracle Linux host is missing a security update.\");\n script_set_attribute(attribute:\"description\", value:\n\"The remote Oracle Linux 7 host has packages installed that are affected by a vulnerability as referenced in the\nELSA-2020-5900 advisory.\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking\n vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format\n includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the\n default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or\n later, the default containerd resolver will provide its authentication credentials if the server where the\n URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker\n publishes a public image with a manifest that directs one of the layers to be fetched from a web server\n they control and they trick a user or system into pulling the image, they can obtain the credentials used\n for pulling that image. In some cases, this may be the user's username and password for the registry. In\n other cases, this may be the credentials attached to the cloud virtual instance which can grant access to\n other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin\n (which can be used by Kubernetes), the ctr development tool, and other client programs that have\n explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and\n later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using\n cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker)\n are not affected. (CVE-2020-15157)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version\nnumber.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://linux.oracle.com/errata/ELSA-2020-5900.html\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected docker-cli and / or docker-engine packages.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:H/Au:N/C:P/I:N/A:N\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2020-15157\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2020/10/28\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2020/10/28\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:oracle:linux:7\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:oracle:linux:docker-cli\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:oracle:linux:docker-engine\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Oracle Linux Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2020-2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/OracleLinux\", \"Host/RedHat/release\", \"Host/RedHat/rpm-list\", \"Host/local_checks_enabled\");\n\n exit(0);\n}\n\n\ninclude('audit.inc');\ninclude('global_settings.inc');\ninclude('rpm.inc');\n\nif (!get_kb_item('Host/local_checks_enabled')) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nif (!get_kb_item('Host/OracleLinux')) audit(AUDIT_OS_NOT, 'Oracle Linux');\nrelease = get_kb_item(\"Host/RedHat/release\");\nif (isnull(release) || !pregmatch(pattern: \"Oracle (?:Linux Server|Enterprise Linux)\", string:release)) audit(AUDIT_OS_NOT, 'Oracle Linux');\nos_ver = pregmatch(pattern: \"Oracle (?:Linux Server|Enterprise Linux) .*release ([0-9]+(\\.[0-9]+)?)\", string:release);\nif (isnull(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, 'Oracle Linux');\nos_ver = os_ver[1];\nif (! preg(pattern:\"^7([^0-9]|$)\", string:os_ver)) audit(AUDIT_OS_NOT, 'Oracle Linux 7', 'Oracle Linux ' + os_ver);\n\nif (!get_kb_item('Host/RedHat/rpm-list')) audit(AUDIT_PACKAGE_LIST_MISSING);\n\ncpu = get_kb_item('Host/cpu');\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif ('x86_64' >!< cpu && cpu !~ \"^i[3-6]86$\" && 'aarch64' >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'Oracle Linux', cpu);\nif ('x86_64' >!< cpu) audit(AUDIT_ARCH_NOT, 'x86_64', cpu);\n\npkgs = [\n {'reference':'docker-cli-19.03.11.ol-6.el7', 'cpu':'x86_64', 'release':'7'},\n {'reference':'docker-engine-19.03.11.ol-6.el7', 'cpu':'x86_64', 'release':'7'}\n];\n\nflag = 0;\nforeach package_array ( pkgs ) {\n reference = NULL;\n release = NULL;\n sp = NULL;\n cpu = NULL;\n el_string = NULL;\n rpm_spec_vers_cmp = NULL;\n epoch = NULL;\n allowmaj = NULL;\n rpm_prefix = NULL;\n if (!empty_or_null(package_array['reference'])) reference = package_array['reference'];\n if (!empty_or_null(package_array['release'])) release = 'EL' + package_array['release'];\n if (!empty_or_null(package_array['sp'])) sp = package_array['sp'];\n if (!empty_or_null(package_array['cpu'])) cpu = package_array['cpu'];\n if (!empty_or_null(package_array['el_string'])) el_string = package_array['el_string'];\n if (!empty_or_null(package_array['rpm_spec_vers_cmp'])) rpm_spec_vers_cmp = package_array['rpm_spec_vers_cmp'];\n if (!empty_or_null(package_array['epoch'])) epoch = package_array['epoch'];\n if (!empty_or_null(package_array['allowmaj'])) allowmaj = package_array['allowmaj'];\n if (!empty_or_null(package_array['rpm_prefix'])) rpm_prefix = package_array['rpm_prefix'];\n if (reference && release) {\n if (rpm_prefix) {\n if (rpm_exists(release:release, rpm:rpm_prefix) && rpm_check(release:release, sp:sp, cpu:cpu, reference:reference, epoch:epoch, el_string:el_string, rpm_spec_vers_cmp:rpm_spec_vers_cmp, allowmaj:allowmaj)) flag++;\n } else {\n if (rpm_check(release:release, sp:sp, cpu:cpu, reference:reference, epoch:epoch, el_string:el_string, rpm_spec_vers_cmp:rpm_spec_vers_cmp, allowmaj:allowmaj)) flag++;\n }\n }\n}\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_NOTE,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, 'docker-cli / docker-engine');\n}", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}, {"lastseen": "2021-08-19T12:12:05", "description": "An update of the containerd package has been released.", "cvss3": {"score": 6.1, "vector": "CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N"}, "published": "2020-10-24T00:00:00", "type": "nessus", "title": "Photon OS 3.0: Containerd PHSA-2020-3.0-0155", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157"], "modified": "2021-03-18T00:00:00", "cpe": ["p-cpe:/a:vmware:photonos:containerd", "cpe:/o:vmware:photonos:3.0"], "id": "PHOTONOS_PHSA-2020-3_0-0155_CONTAINERD.NASL", "href": "https://www.tenable.com/plugins/nessus/141867", "sourceData": "##\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were\n# extracted from VMware Security Advisory PHSA-2020-3.0-0155. The text\n# itself is copyright (C) VMware, Inc.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(141867);\n script_version(\"1.5\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/03/18\");\n\n script_cve_id(\"CVE-2020-15157\");\n\n script_name(english:\"Photon OS 3.0: Containerd PHSA-2020-3.0-0155\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote PhotonOS host is missing multiple security updates.\");\n script_set_attribute(attribute:\"description\", value:\n\"An update of the containerd package has been released.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://github.com/vmware/photon/wiki/Security-Updates-3.0-155.md\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected Linux packages.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:H/Au:N/C:P/I:N/A:N\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2020-15157\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2020/10/24\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2020/10/24\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:vmware:photonos:containerd\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:vmware:photonos:3.0\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"PhotonOS Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2020-2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/PhotonOS/release\", \"Host/PhotonOS/rpm-list\");\n\n exit(0);\n}\n\ninclude('audit.inc');\ninclude('global_settings.inc');\ninclude('rpm.inc');\n\nif (!get_kb_item('Host/local_checks_enabled')) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\n\nrelease = get_kb_item('Host/PhotonOS/release');\nif (isnull(release) || release !~ \"^VMware Photon\") audit(AUDIT_OS_NOT, 'PhotonOS');\nif (release !~ \"^VMware Photon (?:Linux|OS) 3\\.0(\\D|$)\") audit(AUDIT_OS_NOT, 'PhotonOS 3.0');\n\nif (!get_kb_item('Host/PhotonOS/rpm-list')) audit(AUDIT_PACKAGE_LIST_MISSING);\n\ncpu = get_kb_item('Host/cpu');\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif ('x86_64' >!< cpu && cpu !~ \"^i[3-6]86$\" && 'aarch64' >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'PhotonOS', cpu);\n\nflag = 0;\n\nif (rpm_check(release:'PhotonOS-3.0', cpu:'x86_64', reference:'containerd-1.2.14-1.ph3')) flag++;\nif (rpm_check(release:'PhotonOS-3.0', cpu:'x86_64', reference:'containerd-doc-1.2.14-1.ph3')) flag++;\nif (rpm_check(release:'PhotonOS-3.0', cpu:'x86_64', reference:'containerd-extras-1.2.14-1.ph3')) flag++;\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_NOTE,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, 'containerd');\n}\n", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}, {"lastseen": "2021-08-19T12:12:16", "description": "An update of the containerd package has been released.", "cvss3": {"score": 6.1, "vector": "CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N"}, "published": "2020-10-23T00:00:00", "type": "nessus", "title": "Photon OS 2.0: Containerd PHSA-2020-2.0-0292", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157"], "modified": "2021-03-18T00:00:00", "cpe": ["p-cpe:/a:vmware:photonos:containerd", "cpe:/o:vmware:photonos:2.0"], "id": "PHOTONOS_PHSA-2020-2_0-0292_CONTAINERD.NASL", "href": "https://www.tenable.com/plugins/nessus/141858", "sourceData": "##\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were\n# extracted from VMware Security Advisory PHSA-2020-2.0-0292. The text\n# itself is copyright (C) VMware, Inc.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(141858);\n script_version(\"1.5\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/03/18\");\n\n script_cve_id(\"CVE-2020-15157\");\n\n script_name(english:\"Photon OS 2.0: Containerd PHSA-2020-2.0-0292\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote PhotonOS host is missing multiple security updates.\");\n script_set_attribute(attribute:\"description\", value:\n\"An update of the containerd package has been released.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://github.com/vmware/photon/wiki/Security-Updates-2-292.md\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected Linux packages.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:H/Au:N/C:P/I:N/A:N\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2020-15157\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2020/10/23\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2020/10/23\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:vmware:photonos:containerd\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:vmware:photonos:2.0\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"PhotonOS Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2020-2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/PhotonOS/release\", \"Host/PhotonOS/rpm-list\");\n\n exit(0);\n}\n\ninclude('audit.inc');\ninclude('global_settings.inc');\ninclude('rpm.inc');\n\nif (!get_kb_item('Host/local_checks_enabled')) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\n\nrelease = get_kb_item('Host/PhotonOS/release');\nif (isnull(release) || release !~ \"^VMware Photon\") audit(AUDIT_OS_NOT, 'PhotonOS');\nif (release !~ \"^VMware Photon (?:Linux|OS) 2\\.0(\\D|$)\") audit(AUDIT_OS_NOT, 'PhotonOS 2.0');\n\nif (!get_kb_item('Host/PhotonOS/rpm-list')) audit(AUDIT_PACKAGE_LIST_MISSING);\n\ncpu = get_kb_item('Host/cpu');\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif ('x86_64' >!< cpu && cpu !~ \"^i[3-6]86$\" && 'aarch64' >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'PhotonOS', cpu);\n\nflag = 0;\n\nif (rpm_check(release:'PhotonOS-2.0', cpu:'x86_64', reference:'containerd-1.2.14-1.ph2')) flag++;\nif (rpm_check(release:'PhotonOS-2.0', cpu:'x86_64', reference:'containerd-doc-1.2.14-1.ph2')) flag++;\nif (rpm_check(release:'PhotonOS-2.0', cpu:'x86_64', reference:'containerd-extras-1.2.14-1.ph2')) flag++;\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_NOTE,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, 'containerd');\n}\n", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}, {"lastseen": "2021-08-19T12:11:48", "description": "The remote Ubuntu 16.04 LTS / 18.04 LTS / 20.04 LTS host has a package installed that is affected by a vulnerability as referenced in the USN-4589-2 advisory.\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected. (CVE-2020-15157)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.", "cvss3": {"score": 6.1, "vector": "CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N"}, "published": "2020-10-19T00:00:00", "type": "nessus", "title": "Ubuntu 16.04 LTS / 18.04 LTS / 20.04 LTS : Docker vulnerability (USN-4589-2)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157"], "modified": "2021-03-18T00:00:00", "cpe": ["cpe:/o:canonical:ubuntu_linux:16.04:-:lts", "cpe:/o:canonical:ubuntu_linux:18.04:-:lts", "cpe:/o:canonical:ubuntu_linux:20.04:-:lts", "p-cpe:/a:canonical:ubuntu_linux:docker.io"], "id": "UBUNTU_USN-4589-2.NASL", "href": "https://www.tenable.com/plugins/nessus/141538", "sourceData": "##\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were\n# extracted from Ubuntu Security Notice USN-4589-2. The text\n# itself is copyright (C) Canonical, Inc. See\n# <http://www.ubuntu.com/usn/>. Ubuntu(R) is a registered\n# trademark of Canonical, Inc.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(141538);\n script_version(\"1.4\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/03/18\");\n\n script_cve_id(\"CVE-2020-15157\");\n script_xref(name:\"USN\", value:\"4589-2\");\n\n script_name(english:\"Ubuntu 16.04 LTS / 18.04 LTS / 20.04 LTS : Docker vulnerability (USN-4589-2)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote Ubuntu host is missing a security update.\");\n script_set_attribute(attribute:\"description\", value:\n\"The remote Ubuntu 16.04 LTS / 18.04 LTS / 20.04 LTS host has a package installed that is affected by a vulnerability as\nreferenced in the USN-4589-2 advisory.\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking\n vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format\n includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the\n default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or\n later, the default containerd resolver will provide its authentication credentials if the server where the\n URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker\n publishes a public image with a manifest that directs one of the layers to be fetched from a web server\n they control and they trick a user or system into pulling the image, they can obtain the credentials used\n for pulling that image. In some cases, this may be the user's username and password for the registry. In\n other cases, this may be the credentials attached to the cloud virtual instance which can grant access to\n other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin\n (which can be used by Kubernetes), the ctr development tool, and other client programs that have\n explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and\n later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using\n cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker)\n are not affected. (CVE-2020-15157)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version\nnumber.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://ubuntu.com/security/notices/USN-4589-2\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected docker.io package.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:H/Au:N/C:P/I:N/A:N\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2020-15157\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2020/10/15\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2020/10/19\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:canonical:ubuntu_linux:16.04:-:lts\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:canonical:ubuntu_linux:18.04:-:lts\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:canonical:ubuntu_linux:20.04:-:lts\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:canonical:ubuntu_linux:docker.io\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Ubuntu Local Security Checks\");\n\n script_copyright(english:\"Ubuntu Security Notice (C) 2020-2021 Canonical, Inc. / NASL script (C) 2020-2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/cpu\", \"Host/Ubuntu\", \"Host/Ubuntu/release\", \"Host/Debian/dpkg-l\");\n\n exit(0);\n}\n\ninclude('audit.inc');\ninclude('ubuntu.inc');\ninclude('misc_func.inc');\n\nif ( ! get_kb_item('Host/local_checks_enabled') ) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nrelease = get_kb_item('Host/Ubuntu/release');\nif ( isnull(release) ) audit(AUDIT_OS_NOT, 'Ubuntu');\nrelease = chomp(release);\nif (! preg(pattern:\"^(16\\.04|18\\.04|20\\.04)$\", string:release)) audit(AUDIT_OS_NOT, 'Ubuntu 16.04 / 18.04 / 20.04', 'Ubuntu ' + release);\nif ( ! get_kb_item('Host/Debian/dpkg-l') ) audit(AUDIT_PACKAGE_LIST_MISSING);\n\ncpu = get_kb_item('Host/cpu');\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif ('x86_64' >!< cpu && cpu !~ \"^i[3-6]86$\") audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'Ubuntu', cpu);\n\n\npkgs = [\n {'osver': '16.04', 'pkgname': 'docker.io', 'pkgver': '18.09.7-0ubuntu1~16.04.6'},\n {'osver': '18.04', 'pkgname': 'docker.io', 'pkgver': '19.03.6-0ubuntu1~18.04.2'},\n {'osver': '20.04', 'pkgname': 'docker.io', 'pkgver': '19.03.8-0ubuntu1.20.04.1'}\n];\n\nflag = 0;\nforeach package_array ( pkgs ) {\n osver = NULL;\n pkgname = NULL;\n pkgver = NULL;\n if (!empty_or_null(package_array['osver'])) osver = package_array['osver'];\n if (!empty_or_null(package_array['pkgname'])) pkgname = package_array['pkgname'];\n if (!empty_or_null(package_array['pkgver'])) pkgver = package_array['pkgver'];\n if (osver && pkgname && pkgver) {\n if (ubuntu_check(osver:osver, pkgname:pkgname, pkgver:pkgver)) flag++;\n }\n}\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_NOTE,\n extra : ubuntu_report_get()\n );\n exit(0);\n}\nelse\n{\n tested = ubuntu_pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, 'docker.io');\n}", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}, {"lastseen": "2022-04-21T21:38:45", "description": "According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected. (CVE-2020-15157)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where pulling and extracting a specially-crafted container image can result in Unix file permission changes for existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does not directly allow files to be read, modified, or executed without an additional cooperating process. This bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially affected by this bug through policies and profiles that prevent containerd from interacting with specific files. (CVE-2021-32760)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.", "cvss3": {"score": 6.3, "vector": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L"}, "published": "2022-04-21T00:00:00", "type": "nessus", "title": "EulerOS 2.0 SP10 : docker-engine (EulerOS-SA-2022-1482)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157", "CVE-2021-32760"], "modified": "2022-04-21T00:00:00", "cpe": ["p-cpe:/a:huawei:euleros:docker-engine", "p-cpe:/a:huawei:euleros:docker-engine-selinux", "cpe:/o:huawei:euleros:2.0"], "id": "EULEROS_SA-2022-1482.NASL", "href": "https://www.tenable.com/plugins/nessus/160042", "sourceData": "#%NASL_MIN_LEVEL 70300\n##\n# (C) Tenable, Inc.\n##\n\ninclude('deprecated_nasl_level.inc');\ninclude('compat.inc');\n\nif (description)\n{\n script_id(160042);\n script_version(\"1.2\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2022/04/21\");\n\n script_cve_id(\"CVE-2020-15157\", \"CVE-2021-32760\");\n\n script_name(english:\"EulerOS 2.0 SP10 : docker-engine (EulerOS-SA-2022-1482)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote EulerOS host is missing multiple security updates.\");\n script_set_attribute(attribute:\"description\", value:\n\"According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is\naffected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking\n vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format\n includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the\n default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or\n later, the default containerd resolver will provide its authentication credentials if the server where the\n URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker\n publishes a public image with a manifest that directs one of the layers to be fetched from a web server\n they control and they trick a user or system into pulling the image, they can obtain the credentials used\n for pulling that image. In some cases, this may be the user's username and password for the registry. In\n other cases, this may be the credentials attached to the cloud virtual instance which can grant access to\n other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin\n (which can be used by Kubernetes), the ctr development tool, and other client programs that have\n explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and\n later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using\n cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker)\n are not affected. (CVE-2020-15157)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where\n pulling and extracting a specially-crafted container image can result in Unix file permission changes for\n existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner\n of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does\n not directly allow files to be read, modified, or executed without an additional cooperating process. This\n bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from\n trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially\n affected by this bug through policies and profiles that prevent containerd from interacting with specific\n files. (CVE-2021-32760)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security\nadvisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional\nissues.\");\n # https://developer.huaweicloud.com/ict/en/site-euleros/euleros/security-advisories/EulerOS-SA-2022-1482\n script_set_attribute(attribute:\"see_also\", value:\"http://www.nessus.org/u?8be201f3\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected docker-engine packages.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-32760\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"false\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2022/04/20\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2022/04/21\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine-selinux\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:huawei:euleros:2.0\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Huawei Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2022 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/cpu\", \"Host/EulerOS/release\", \"Host/EulerOS/rpm-list\", \"Host/EulerOS/sp\");\n script_exclude_keys(\"Host/EulerOS/uvp_version\");\n\n exit(0);\n}\n\ninclude(\"rpm.inc\");\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\n\nvar release = get_kb_item(\"Host/EulerOS/release\");\nif (isnull(release) || release !~ \"^EulerOS\") audit(AUDIT_OS_NOT, \"EulerOS\");\nvar uvp = get_kb_item(\"Host/EulerOS/uvp_version\");\nif (release !~ \"^EulerOS release 2\\.0(\\D|$)\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP10\");\n\nvar sp = get_kb_item(\"Host/EulerOS/sp\");\nif (isnull(sp) || sp !~ \"^(10)$\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP10\");\n\nif (!empty_or_null(uvp)) audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP10\", \"EulerOS UVP \" + uvp);\n\nif (!get_kb_item(\"Host/EulerOS/rpm-list\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\nvar cpu = get_kb_item(\"Host/cpu\");\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\" && \"aarch64\" >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, \"EulerOS\", cpu);\nif (\"aarch64\" >!< cpu) audit(AUDIT_ARCH_NOT, \"aarch64\", cpu);\n\nvar flag = 0;\n\nvar pkgs = [\n \"docker-engine-18.09.0.200-200.h41.25.14.eulerosv2r10\",\n \"docker-engine-selinux-18.09.0.200-200.h41.25.14.eulerosv2r10\"\n];\n\nforeach (var pkg in pkgs)\n if (rpm_check(release:\"EulerOS-2.0\", sp:\"10\", reference:pkg)) flag++;\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_WARNING,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n var tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, \"docker-engine\");\n}\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2022-04-21T06:01:34", "description": "According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected. (CVE-2020-15157)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where pulling and extracting a specially-crafted container image can result in Unix file permission changes for existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does not directly allow files to be read, modified, or executed without an additional cooperating process. This bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially affected by this bug through policies and profiles that prevent containerd from interacting with specific files. (CVE-2021-32760)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.", "cvss3": {"score": 6.3, "vector": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L"}, "published": "2022-04-20T00:00:00", "type": "nessus", "title": "EulerOS 2.0 SP10 : docker-engine (EulerOS-SA-2022-1501)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157", "CVE-2021-32760"], "modified": "2022-04-20T00:00:00", "cpe": ["p-cpe:/a:huawei:euleros:docker-engine", "p-cpe:/a:huawei:euleros:docker-engine-selinux", "cpe:/o:huawei:euleros:2.0"], "id": "EULEROS_SA-2022-1501.NASL", "href": "https://www.tenable.com/plugins/nessus/160004", "sourceData": "#%NASL_MIN_LEVEL 70300\n##\n# (C) Tenable, Inc.\n##\n\ninclude('deprecated_nasl_level.inc');\ninclude('compat.inc');\n\nif (description)\n{\n script_id(160004);\n script_version(\"1.2\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2022/04/20\");\n\n script_cve_id(\"CVE-2020-15157\", \"CVE-2021-32760\");\n\n script_name(english:\"EulerOS 2.0 SP10 : docker-engine (EulerOS-SA-2022-1501)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote EulerOS host is missing multiple security updates.\");\n script_set_attribute(attribute:\"description\", value:\n\"According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is\naffected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking\n vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format\n includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the\n default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or\n later, the default containerd resolver will provide its authentication credentials if the server where the\n URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker\n publishes a public image with a manifest that directs one of the layers to be fetched from a web server\n they control and they trick a user or system into pulling the image, they can obtain the credentials used\n for pulling that image. In some cases, this may be the user's username and password for the registry. In\n other cases, this may be the credentials attached to the cloud virtual instance which can grant access to\n other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin\n (which can be used by Kubernetes), the ctr development tool, and other client programs that have\n explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and\n later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using\n cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker)\n are not affected. (CVE-2020-15157)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where\n pulling and extracting a specially-crafted container image can result in Unix file permission changes for\n existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner\n of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does\n not directly allow files to be read, modified, or executed without an additional cooperating process. This\n bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from\n trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially\n affected by this bug through policies and profiles that prevent containerd from interacting with specific\n files. (CVE-2021-32760)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security\nadvisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional\nissues.\");\n # https://developer.huaweicloud.com/ict/en/site-euleros/euleros/security-advisories/EulerOS-SA-2022-1501\n script_set_attribute(attribute:\"see_also\", value:\"http://www.nessus.org/u?d066788c\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected docker-engine packages.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-32760\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"false\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2022/04/20\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2022/04/20\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine-selinux\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:huawei:euleros:2.0\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Huawei Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2022 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/cpu\", \"Host/EulerOS/release\", \"Host/EulerOS/rpm-list\", \"Host/EulerOS/sp\");\n script_exclude_keys(\"Host/EulerOS/uvp_version\");\n\n exit(0);\n}\n\ninclude(\"rpm.inc\");\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\n\nvar release = get_kb_item(\"Host/EulerOS/release\");\nif (isnull(release) || release !~ \"^EulerOS\") audit(AUDIT_OS_NOT, \"EulerOS\");\nvar uvp = get_kb_item(\"Host/EulerOS/uvp_version\");\nif (release !~ \"^EulerOS release 2\\.0(\\D|$)\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP10\");\n\nvar sp = get_kb_item(\"Host/EulerOS/sp\");\nif (isnull(sp) || sp !~ \"^(10)$\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP10\");\n\nif (!empty_or_null(uvp)) audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP10\", \"EulerOS UVP \" + uvp);\n\nif (!get_kb_item(\"Host/EulerOS/rpm-list\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\nvar cpu = get_kb_item(\"Host/cpu\");\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\" && \"aarch64\" >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, \"EulerOS\", cpu);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\") audit(AUDIT_ARCH_NOT, \"i686 / x86_64\", cpu);\n\nvar flag = 0;\n\nvar pkgs = [\n \"docker-engine-18.09.0.200-200.h41.25.14.eulerosv2r10\",\n \"docker-engine-selinux-18.09.0.200-200.h41.25.14.eulerosv2r10\"\n];\n\nforeach (var pkg in pkgs)\n if (rpm_check(release:\"EulerOS-2.0\", sp:\"10\", reference:pkg)) flag++;\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_WARNING,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n var tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, \"docker-engine\");\n}\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2022-05-06T23:32:29", "description": "According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected. (CVE-2020-15157)\n\n - In Docker before versions 9.03.15, 20.10.3 there is a vulnerability involving the --userns-remap option in which access to remapped root allows privilege escalation to real root. When using '--userns-remap', if the root user in the remapped namespace has access to the host filesystem they can modify files under '/var/lib/docker/<remapping>' that cause writing files with extended privileges. Versions 20.10.3 and 19.03.15 contain patches that prevent privilege escalation from remapped user. (CVE-2021-21284)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where pulling and extracting a specially-crafted container image can result in Unix file permission changes for existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does not directly allow files to be read, modified, or executed without an additional cooperating process. This bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially affected by this bug through policies and profiles that prevent containerd from interacting with specific files. (CVE-2021-32760)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.", "cvss3": {"score": 6.8, "vector": "CVSS:3.0/AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N"}, "published": "2022-04-18T00:00:00", "type": "nessus", "title": "EulerOS 2.0 SP9 : docker-engine (EulerOS-SA-2022-1445)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157", "CVE-2021-21284", "CVE-2021-32760"], "modified": "2022-05-06T00:00:00", "cpe": ["p-cpe:/a:huawei:euleros:docker-engine", "p-cpe:/a:huawei:euleros:docker-engine-selinux", "cpe:/o:huawei:euleros:2.0"], "id": "EULEROS_SA-2022-1445.NASL", "href": "https://www.tenable.com/plugins/nessus/159808", "sourceData": "#%NASL_MIN_LEVEL 70300\n##\n# (C) Tenable, Inc.\n##\n\ninclude('deprecated_nasl_level.inc');\ninclude('compat.inc');\n\nif (description)\n{\n script_id(159808);\n script_version(\"1.3\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2022/05/06\");\n\n script_cve_id(\"CVE-2020-15157\", \"CVE-2021-21284\", \"CVE-2021-32760\");\n\n script_name(english:\"EulerOS 2.0 SP9 : docker-engine (EulerOS-SA-2022-1445)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote EulerOS host is missing multiple security updates.\");\n script_set_attribute(attribute:\"description\", value:\n\"According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is\naffected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking\n vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format\n includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the\n default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or\n later, the default containerd resolver will provide its authentication credentials if the server where the\n URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker\n publishes a public image with a manifest that directs one of the layers to be fetched from a web server\n they control and they trick a user or system into pulling the image, they can obtain the credentials used\n for pulling that image. In some cases, this may be the user's username and password for the registry. In\n other cases, this may be the credentials attached to the cloud virtual instance which can grant access to\n other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin\n (which can be used by Kubernetes), the ctr development tool, and other client programs that have\n explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and\n later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using\n cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker)\n are not affected. (CVE-2020-15157)\n\n - In Docker before versions 9.03.15, 20.10.3 there is a vulnerability involving the --userns-remap option in\n which access to remapped root allows privilege escalation to real root. When using '--userns-remap', if\n the root user in the remapped namespace has access to the host filesystem they can modify files under\n '/var/lib/docker/<remapping>' that cause writing files with extended privileges. Versions 20.10.3 and\n 19.03.15 contain patches that prevent privilege escalation from remapped user. (CVE-2021-21284)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where\n pulling and extracting a specially-crafted container image can result in Unix file permission changes for\n existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner\n of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does\n not directly allow files to be read, modified, or executed without an additional cooperating process. This\n bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from\n trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially\n affected by this bug through policies and profiles that prevent containerd from interacting with specific\n files. (CVE-2021-32760)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security\nadvisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional\nissues.\");\n # https://developer.huaweicloud.com/ict/en/site-euleros/euleros/security-advisories/EulerOS-SA-2022-1445\n script_set_attribute(attribute:\"see_also\", value:\"http://www.nessus.org/u?f8fa829b\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected docker-engine packages.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-32760\");\n script_set_attribute(attribute:\"cvss3_score_source\", value:\"CVE-2021-21284\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"false\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2022/04/18\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2022/04/18\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine-selinux\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:huawei:euleros:2.0\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Huawei Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2022 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/cpu\", \"Host/EulerOS/release\", \"Host/EulerOS/rpm-list\", \"Host/EulerOS/sp\");\n script_exclude_keys(\"Host/EulerOS/uvp_version\");\n\n exit(0);\n}\n\ninclude(\"rpm.inc\");\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\n\nvar release = get_kb_item(\"Host/EulerOS/release\");\nif (isnull(release) || release !~ \"^EulerOS\") audit(AUDIT_OS_NOT, \"EulerOS\");\nvar uvp = get_kb_item(\"Host/EulerOS/uvp_version\");\nif (release !~ \"^EulerOS release 2\\.0(\\D|$)\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP9\");\n\nvar sp = get_kb_item(\"Host/EulerOS/sp\");\nif (isnull(sp) || sp !~ \"^(9)$\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP9\");\n\nif (!empty_or_null(uvp)) audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP9\", \"EulerOS UVP \" + uvp);\n\nif (!get_kb_item(\"Host/EulerOS/rpm-list\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\nvar cpu = get_kb_item(\"Host/cpu\");\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\" && \"aarch64\" >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, \"EulerOS\", cpu);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\") audit(AUDIT_ARCH_NOT, \"i686 / x86_64\", cpu);\n\nvar flag = 0;\n\nvar pkgs = [\n \"docker-engine-18.09.0.129-1.h55.25.11.eulerosv2r9\",\n \"docker-engine-selinux-18.09.0.129-1.h55.25.11.eulerosv2r9\"\n];\n\nforeach (var pkg in pkgs)\n if (rpm_check(release:\"EulerOS-2.0\", sp:\"9\", reference:pkg)) flag++;\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_WARNING,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n var tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, \"docker-engine\");\n}\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2022-05-06T23:32:07", "description": "According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected. (CVE-2020-15157)\n\n - In Docker before versions 9.03.15, 20.10.3 there is a vulnerability involving the --userns-remap option in which access to remapped root allows privilege escalation to real root. When using '--userns-remap', if the root user in the remapped namespace has access to the host filesystem they can modify files under '/var/lib/docker/<remapping>' that cause writing files with extended privileges. Versions 20.10.3 and 19.03.15 contain patches that prevent privilege escalation from remapped user. (CVE-2021-21284)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where pulling and extracting a specially-crafted container image can result in Unix file permission changes for existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does not directly allow files to be read, modified, or executed without an additional cooperating process. This bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially affected by this bug through policies and profiles that prevent containerd from interacting with specific files. (CVE-2021-32760)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.", "cvss3": {"score": 6.8, "vector": "CVSS:3.0/AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N"}, "published": "2022-04-18T00:00:00", "type": "nessus", "title": "EulerOS 2.0 SP9 : docker-engine (EulerOS-SA-2022-1424)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157", "CVE-2021-21284", "CVE-2021-32760"], "modified": "2022-05-06T00:00:00", "cpe": ["p-cpe:/a:huawei:euleros:docker-engine", "p-cpe:/a:huawei:euleros:docker-engine-selinux", "cpe:/o:huawei:euleros:2.0"], "id": "EULEROS_SA-2022-1424.NASL", "href": "https://www.tenable.com/plugins/nessus/159804", "sourceData": "#%NASL_MIN_LEVEL 70300\n##\n# (C) Tenable, Inc.\n##\n\ninclude('deprecated_nasl_level.inc');\ninclude('compat.inc');\n\nif (description)\n{\n script_id(159804);\n script_version(\"1.3\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2022/05/06\");\n\n script_cve_id(\"CVE-2020-15157\", \"CVE-2021-21284\", \"CVE-2021-32760\");\n\n script_name(english:\"EulerOS 2.0 SP9 : docker-engine (EulerOS-SA-2022-1424)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote EulerOS host is missing multiple security updates.\");\n script_set_attribute(attribute:\"description\", value:\n\"According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is\naffected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking\n vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format\n includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the\n default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or\n later, the default containerd resolver will provide its authentication credentials if the server where the\n URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker\n publishes a public image with a manifest that directs one of the layers to be fetched from a web server\n they control and they trick a user or system into pulling the image, they can obtain the credentials used\n for pulling that image. In some cases, this may be the user's username and password for the registry. In\n other cases, this may be the credentials attached to the cloud virtual instance which can grant access to\n other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin\n (which can be used by Kubernetes), the ctr development tool, and other client programs that have\n explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and\n later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using\n cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker)\n are not affected. (CVE-2020-15157)\n\n - In Docker before versions 9.03.15, 20.10.3 there is a vulnerability involving the --userns-remap option in\n which access to remapped root allows privilege escalation to real root. When using '--userns-remap', if\n the root user in the remapped namespace has access to the host filesystem they can modify files under\n '/var/lib/docker/<remapping>' that cause writing files with extended privileges. Versions 20.10.3 and\n 19.03.15 contain patches that prevent privilege escalation from remapped user. (CVE-2021-21284)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where\n pulling and extracting a specially-crafted container image can result in Unix file permission changes for\n existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner\n of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does\n not directly allow files to be read, modified, or executed without an additional cooperating process. This\n bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from\n trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially\n affected by this bug through policies and profiles that prevent containerd from interacting with specific\n files. (CVE-2021-32760)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security\nadvisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional\nissues.\");\n # https://developer.huaweicloud.com/ict/en/site-euleros/euleros/security-advisories/EulerOS-SA-2022-1424\n script_set_attribute(attribute:\"see_also\", value:\"http://www.nessus.org/u?9df58b92\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected docker-engine packages.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-32760\");\n script_set_attribute(attribute:\"cvss3_score_source\", value:\"CVE-2021-21284\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"false\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2022/04/18\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2022/04/18\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine-selinux\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:huawei:euleros:2.0\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Huawei Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2022 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/cpu\", \"Host/EulerOS/release\", \"Host/EulerOS/rpm-list\", \"Host/EulerOS/sp\");\n script_exclude_keys(\"Host/EulerOS/uvp_version\");\n\n exit(0);\n}\n\ninclude(\"rpm.inc\");\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\n\nvar release = get_kb_item(\"Host/EulerOS/release\");\nif (isnull(release) || release !~ \"^EulerOS\") audit(AUDIT_OS_NOT, \"EulerOS\");\nvar uvp = get_kb_item(\"Host/EulerOS/uvp_version\");\nif (release !~ \"^EulerOS release 2\\.0(\\D|$)\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP9\");\n\nvar sp = get_kb_item(\"Host/EulerOS/sp\");\nif (isnull(sp) || sp !~ \"^(9)$\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP9\");\n\nif (!empty_or_null(uvp)) audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP9\", \"EulerOS UVP \" + uvp);\n\nif (!get_kb_item(\"Host/EulerOS/rpm-list\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\nvar cpu = get_kb_item(\"Host/cpu\");\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\" && \"aarch64\" >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, \"EulerOS\", cpu);\nif (\"aarch64\" >!< cpu) audit(AUDIT_ARCH_NOT, \"aarch64\", cpu);\n\nvar flag = 0;\n\nvar pkgs = [\n \"docker-engine-18.09.0.129-1.h55.25.11.eulerosv2r9\",\n \"docker-engine-selinux-18.09.0.129-1.h55.25.11.eulerosv2r9\"\n];\n\nforeach (var pkg in pkgs)\n if (rpm_check(release:\"EulerOS-2.0\", sp:\"9\", reference:pkg)) flag++;\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_WARNING,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n var tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, \"docker-engine\");\n}\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2022-06-22T16:29:48", "description": "According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected. (CVE-2020-15157)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where pulling and extracting a specially-crafted container image can result in Unix file permission changes for existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does not directly allow files to be read, modified, or executed without an additional cooperating process. This bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially affected by this bug through policies and profiles that prevent containerd from interacting with specific files. (CVE-2021-32760)\n\n - containerd is an open source container runtime with an emphasis on simplicity, robustness and portability.\n A bug was found in containerd where container root directories and some plugins had insufficiently restricted permissions, allowing otherwise unprivileged Linux users to traverse directory contents and execute programs. When containers included executable programs with extended permission bits (such as setuid), unprivileged Linux users could discover and execute those programs. When the UID of an unprivileged Linux user on the host collided with the file owner or group inside a container, the unprivileged Linux user on the host could discover, read, and modify those files. This vulnerability has been fixed in containerd 1.4.11 and containerd 1.5.7. Users should update to these version when they are released and may restart containers or update directory permissions to mitigate the vulnerability. Users unable to update should limit access to the host to trusted users. Update directory permission on container bundles directories. (CVE-2021-41103)\n\n - Moby is an open-source project created by Docker to enable and accelerate software containerization. A bug was found in Moby (Docker Engine) prior to version 20.10.14 where containers were incorrectly started with non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling programs with inheritable file capabilities to elevate those capabilities to the permitted set during `execve(2)`. Normally, when executable programs have specified permitted file capabilities, otherwise unprivileged users and processes can execute those programs and gain the specified file capabilities up to the bounding set. Due to this bug, containers which included executable programs with inheritable file capabilities allowed otherwise unprivileged users and processes to additionally gain these inheritable file capabilities up to the container's bounding set. Containers which use Linux users and groups to perform privilege separation inside the container are most directly impacted. This bug did not affect the container security sandbox as the inheritable set never contained more capabilities than were included in the container's bounding set. This bug has been fixed in Moby (Docker Engine) 20.10.14. Running containers should be stopped, deleted, and recreated for the inheritable capabilities to be reset. This fix changes Moby (Docker Engine) behavior such that containers are started with a more typical Linux environment. As a workaround, the entry point of a container can be modified to use a utility like `capsh(1)` to drop inheritable capabilities prior to the primary process starting. (CVE-2022-24769)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.", "cvss3": {"score": 7.8, "vector": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"}, "published": "2022-06-22T00:00:00", "type": "nessus", "title": "EulerOS 2.0 SP8 : docker-engine (EulerOS-SA-2022-1926)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157", "CVE-2021-32760", "CVE-2021-41103", "CVE-2022-24769"], "modified": "2022-06-22T00:00:00", "cpe": ["p-cpe:/a:huawei:euleros:docker-engine", "p-cpe:/a:huawei:euleros:docker-engine-selinux", "cpe:/o:huawei:euleros:2.0"], "id": "EULEROS_SA-2022-1926.NASL", "href": "https://www.tenable.com/plugins/nessus/162441", "sourceData": "##\n# (C) Tenable, Inc.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(162441);\n script_version(\"1.2\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2022/06/22\");\n\n script_cve_id(\n \"CVE-2020-15157\",\n \"CVE-2021-32760\",\n \"CVE-2021-41103\",\n \"CVE-2022-24769\"\n );\n\n script_name(english:\"EulerOS 2.0 SP8 : docker-engine (EulerOS-SA-2022-1926)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote EulerOS host is missing multiple security updates.\");\n script_set_attribute(attribute:\"description\", value:\n\"According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is\naffected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking\n vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format\n includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the\n default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or\n later, the default containerd resolver will provide its authentication credentials if the server where the\n URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker\n publishes a public image with a manifest that directs one of the layers to be fetched from a web server\n they control and they trick a user or system into pulling the image, they can obtain the credentials used\n for pulling that image. In some cases, this may be the user's username and password for the registry. In\n other cases, this may be the credentials attached to the cloud virtual instance which can grant access to\n other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin\n (which can be used by Kubernetes), the ctr development tool, and other client programs that have\n explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and\n later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using\n cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker)\n are not affected. (CVE-2020-15157)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where\n pulling and extracting a specially-crafted container image can result in Unix file permission changes for\n existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner\n of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does\n not directly allow files to be read, modified, or executed without an additional cooperating process. This\n bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from\n trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially\n affected by this bug through policies and profiles that prevent containerd from interacting with specific\n files. (CVE-2021-32760)\n\n - containerd is an open source container runtime with an emphasis on simplicity, robustness and portability.\n A bug was found in containerd where container root directories and some plugins had insufficiently\n restricted permissions, allowing otherwise unprivileged Linux users to traverse directory contents and\n execute programs. When containers included executable programs with extended permission bits (such as\n setuid), unprivileged Linux users could discover and execute those programs. When the UID of an\n unprivileged Linux user on the host collided with the file owner or group inside a container, the\n unprivileged Linux user on the host could discover, read, and modify those files. This vulnerability has\n been fixed in containerd 1.4.11 and containerd 1.5.7. Users should update to these version when they are\n released and may restart containers or update directory permissions to mitigate the vulnerability. Users\n unable to update should limit access to the host to trusted users. Update directory permission on\n container bundles directories. (CVE-2021-41103)\n\n - Moby is an open-source project created by Docker to enable and accelerate software containerization. A bug\n was found in Moby (Docker Engine) prior to version 20.10.14 where containers were incorrectly started with\n non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling\n programs with inheritable file capabilities to elevate those capabilities to the permitted set during\n `execve(2)`. Normally, when executable programs have specified permitted file capabilities, otherwise\n unprivileged users and processes can execute those programs and gain the specified file capabilities up to\n the bounding set. Due to this bug, containers which included executable programs with inheritable file\n capabilities allowed otherwise unprivileged users and processes to additionally gain these inheritable\n file capabilities up to the container's bounding set. Containers which use Linux users and groups to\n perform privilege separation inside the container are most directly impacted. This bug did not affect the\n container security sandbox as the inheritable set never contained more capabilities than were included in\n the container's bounding set. This bug has been fixed in Moby (Docker Engine) 20.10.14. Running containers\n should be stopped, deleted, and recreated for the inheritable capabilities to be reset. This fix changes\n Moby (Docker Engine) behavior such that containers are started with a more typical Linux environment. As a\n workaround, the entry point of a container can be modified to use a utility like `capsh(1)` to drop\n inheritable capabilities prior to the primary process starting. (CVE-2022-24769)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security\nadvisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional\nissues.\");\n # https://developer.huaweicloud.com/ict/en/site-euleros/euleros/security-advisories/EulerOS-SA-2022-1926\n script_set_attribute(attribute:\"see_also\", value:\"http://www.nessus.org/u?d4654544\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected docker-engine packages.\");\n script_set_cvss_base_vector(\"CVSS2#AV:L/AC:L/Au:N/C:C/I:C/A:C\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-41103\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"false\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2022/06/22\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2022/06/22\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine-selinux\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:huawei:euleros:2.0\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Huawei Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2022 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/cpu\", \"Host/EulerOS/release\", \"Host/EulerOS/rpm-list\", \"Host/EulerOS/sp\");\n script_exclude_keys(\"Host/EulerOS/uvp_version\");\n\n exit(0);\n}\n\ninclude(\"rpm.inc\");\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\n\nvar release = get_kb_item(\"Host/EulerOS/release\");\nif (isnull(release) || release !~ \"^EulerOS\") audit(AUDIT_OS_NOT, \"EulerOS\");\nvar uvp = get_kb_item(\"Host/EulerOS/uvp_version\");\nif (release !~ \"^EulerOS release 2\\.0(\\D|$)\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP8\");\n\nvar sp = get_kb_item(\"Host/EulerOS/sp\");\nif (isnull(sp) || sp !~ \"^(8)$\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP8\");\n\nif (!empty_or_null(uvp)) audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP8\", \"EulerOS UVP \" + uvp);\n\nif (!get_kb_item(\"Host/EulerOS/rpm-list\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\nvar cpu = get_kb_item(\"Host/cpu\");\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\" && \"aarch64\" >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, \"EulerOS\", cpu);\nif (\"aarch64\" >!< cpu) audit(AUDIT_ARCH_NOT, \"aarch64\", cpu);\n\nvar flag = 0;\n\nvar pkgs = [\n \"docker-engine-18.09.0.101-1.h52.22.10.eulerosv2r8\",\n \"docker-engine-selinux-18.09.0.101-1.h52.22.10.eulerosv2r8\"\n];\n\nforeach (var pkg in pkgs)\n if (rpm_check(release:\"EulerOS-2.0\", sp:\"8\", reference:pkg)) flag++;\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_HOLE,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n var tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, \"docker-engine\");\n}\n", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2022-07-12T14:46:01", "description": "Multiple security issues were discovered in Docker, a Linux container runtime, which could result in denial of service, an information leak or privilege escalation.", "cvss3": {"score": 6.8, "vector": "CVSS:3.0/AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N"}, "published": "2021-03-01T00:00:00", "type": "nessus", "title": "Debian DSA-4865-1 : docker.io - security update", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157", "CVE-2020-15257", "CVE-2021-21284", "CVE-2021-21285"], "modified": "2022-05-11T00:00:00", "cpe": ["cpe:2.3:o:debian:debian_linux:10.0:*:*:*:*:*:*:*", "p-cpe:2.3:a:debian:debian_linux:docker.io:*:*:*:*:*:*:*"], "id": "DEBIAN_DSA-4865.NASL", "href": "https://www.tenable.com/plugins/nessus/146922", "sourceData": "#\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were \n# extracted from Debian Security Advisory DSA-4865. The text \n# itself is copyright (C) Software in the Public Interest, Inc.\n#\n\ninclude(\"compat.inc\");\n\nif (description)\n{\n script_id(146922);\n script_version(\"1.4\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2022/05/11\");\n\n script_cve_id(\"CVE-2020-15157\", \"CVE-2020-15257\", \"CVE-2021-21284\", \"CVE-2021-21285\");\n script_xref(name:\"DSA\", value:\"4865\");\n\n script_name(english:\"Debian DSA-4865-1 : docker.io - security update\");\n script_summary(english:\"Checks dpkg output for the updated package\");\n\n script_set_attribute(\n attribute:\"synopsis\",\n value:\"The remote Debian host is missing a security-related update.\"\n );\n script_set_attribute(\n attribute:\"description\",\n value:\n\"Multiple security issues were discovered in Docker, a Linux container\nruntime, which could result in denial of service, an information leak\nor privilege escalation.\"\n );\n script_set_attribute(\n attribute:\"see_also\",\n value:\"https://security-tracker.debian.org/tracker/source-package/docker.io\"\n );\n script_set_attribute(\n attribute:\"see_also\",\n value:\"https://packages.debian.org/source/buster/docker.io\"\n );\n script_set_attribute(\n attribute:\"see_also\",\n value:\"https://www.debian.org/security/2021/dsa-4865\"\n );\n script_set_attribute(\n attribute:\"solution\",\n value:\n\"Upgrade the docker.io packages.\n\nFor the stable distribution (buster), these problems have been fixed\nin version 18.09.1+dfsg1-7.1+deb10u3.\"\n );\n script_set_cvss_base_vector(\"CVSS2#AV:L/AC:L/Au:N/C:P/I:P/A:N\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2020-15257\");\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"false\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:debian:debian_linux:docker.io\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:debian:debian_linux:10.0\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2021/02/27\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2021/03/01\");\n script_set_attribute(attribute:\"generated_plugin\", value:\"current\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_copyright(english:\"This script is Copyright (C) 2021-2022 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n script_family(english:\"Debian Local Security Checks\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/Debian/release\", \"Host/Debian/dpkg-l\");\n\n exit(0);\n}\n\n\ninclude(\"audit.inc\");\ninclude(\"debian_package.inc\");\n\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nif (!get_kb_item(\"Host/Debian/release\")) audit(AUDIT_OS_NOT, \"Debian\");\nif (!get_kb_item(\"Host/Debian/dpkg-l\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\n\nflag = 0;\nif (deb_check(release:\"10.0\", prefix:\"docker-doc\", reference:\"18.09.1+dfsg1-7.1+deb10u3\")) flag++;\nif (deb_check(release:\"10.0\", prefix:\"docker.io\", reference:\"18.09.1+dfsg1-7.1+deb10u3\")) flag++;\nif (deb_check(release:\"10.0\", prefix:\"golang-docker-dev\", reference:\"18.09.1+dfsg1-7.1+deb10u3\")) flag++;\nif (deb_check(release:\"10.0\", prefix:\"golang-github-docker-docker-dev\", reference:\"18.09.1+dfsg1-7.1+deb10u3\")) flag++;\nif (deb_check(release:\"10.0\", prefix:\"vim-syntax-docker\", reference:\"18.09.1+dfsg1-7.1+deb10u3\")) flag++;\n\nif (flag)\n{\n if (report_verbosity > 0) security_note(port:0, extra:deb_report_get());\n else security_note(0);\n exit(0);\n}\nelse audit(AUDIT_HOST_NOT, \"affected\");\n", "cvss": {"score": 3.6, "vector": "CVSS2#AV:L/AC:L/Au:N/C:P/I:P/A:N"}}, {"lastseen": "2022-06-17T12:21:20", "description": "According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected. (CVE-2020-15157)\n\n - containerd is an industry-standard container runtime and is available as a daemon for Linux and Windows.\n In containerd before versions 1.3.9 and 1.4.3, the containerd-shim API is improperly exposed to host network containers. Access controls for the shim's API socket verified that the connecting process had an effective UID of 0, but did not otherwise restrict access to the abstract Unix domain socket. This would allow malicious containers running in the same network namespace as the shim, with an effective UID of 0 but otherwise reduced privileges, to cause new processes to be run with elevated privileges. This vulnerability has been fixed in containerd 1.3.9 and 1.4.3. Users should update to these versions as soon as they are released. It should be noted that containers started with an old version of containerd-shim should be stopped and restarted, as running containers will continue to be vulnerable even after an upgrade. If you are not providing the ability for untrusted users to start containers in the same network namespace as the shim (typically the 'host' network namespace, for example with docker run --net=host or hostNetwork: true in a Kubernetes pod) and run with an effective UID of 0, you are not vulnerable to this issue. If you are running containers with a vulnerable configuration, you can deny access to all abstract sockets with AppArmor by adding a line similar to deny unix addr=@**, to your policy. It is best practice to run containers with a reduced set of privileges, with a non-zero UID, and with isolated namespaces. The containerd maintainers strongly advise against sharing namespaces with the host. Reducing the set of isolation mechanisms used for a container necessarily increases that container's privilege, regardless of what container runtime is used for running that container. (CVE-2020-15257)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where pulling and extracting a specially-crafted container image can result in Unix file permission changes for existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does not directly allow files to be read, modified, or executed without an additional cooperating process. This bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially affected by this bug through policies and profiles that prevent containerd from interacting with specific files. (CVE-2021-32760)\n\n - containerd is an open source container runtime with an emphasis on simplicity, robustness and portability.\n A bug was found in containerd where container root directories and some plugins had insufficiently restricted permissions, allowing otherwise unprivileged Linux users to traverse directory contents and execute programs. When containers included executable programs with extended permission bits (such as setuid), unprivileged Linux users could discover and execute those programs. When the UID of an unprivileged Linux user on the host collided with the file owner or group inside a container, the unprivileged Linux user on the host could discover, read, and modify those files. This vulnerability has been fixed in containerd 1.4.11 and containerd 1.5.7. Users should update to these version when they are released and may restart containers or update directory permissions to mitigate the vulnerability. Users unable to update should limit access to the host to trusted users. Update directory permission on container bundles directories. (CVE-2021-41103)\n\n - Moby is an open-source project created by Docker to enable and accelerate software containerization. A bug was found in Moby (Docker Engine) prior to version 20.10.14 where containers were incorrectly started with non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling programs with inheritable file capabilities to elevate those capabilities to the permitted set during `execve(2)`. Normally, when executable programs have specified permitted file capabilities, otherwise unprivileged users and processes can execute those programs and gain the specified file capabilities up to the bounding set. Due to this bug, containers which included executable programs with inheritable file capabilities allowed otherwise unprivileged users and processes to additionally gain these inheritable file capabilities up to the container's bounding set. Containers which use Linux users and groups to perform privilege separation inside the container are most directly impacted. This bug did not affect the container security sandbox as the inheritable set never contained more capabilities than were included in the container's bounding set. This bug has been fixed in Moby (Docker Engine) 20.10.14. Running containers should be stopped, deleted, and recreated for the inheritable capabilities to be reset. This fix changes Moby (Docker Engine) behavior such that containers are started with a more typical Linux environment. As a workaround, the entry point of a container can be modified to use a utility like `capsh(1)` to drop inheritable capabilities prior to the primary process starting. (CVE-2022-24769)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.", "cvss3": {"score": 7.8, "vector": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"}, "published": "2022-06-17T00:00:00", "type": "nessus", "title": "EulerOS 2.0 SP5 : docker-engine (EulerOS-SA-2022-1886)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-15157", "CVE-2020-15257", "CVE-2021-32760", "CVE-2021-41103", "CVE-2022-24769"], "modified": "2022-06-17T00:00:00", "cpe": ["p-cpe:/a:huawei:euleros:docker-engine", "p-cpe:/a:huawei:euleros:docker-engine-selinux", "cpe:/o:huawei:euleros:2.0"], "id": "EULEROS_SA-2022-1886.NASL", "href": "https://www.tenable.com/plugins/nessus/162362", "sourceData": "##\n# (C) Tenable, Inc.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(162362);\n script_version(\"1.2\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2022/06/17\");\n\n script_cve_id(\n \"CVE-2020-15157\",\n \"CVE-2020-15257\",\n \"CVE-2021-32760\",\n \"CVE-2021-41103\",\n \"CVE-2022-24769\"\n );\n\n script_name(english:\"EulerOS 2.0 SP5 : docker-engine (EulerOS-SA-2022-1886)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote EulerOS host is missing multiple security updates.\");\n script_set_attribute(attribute:\"description\", value:\n\"According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is\naffected by the following vulnerabilities :\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking\n vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format\n includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the\n default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or\n later, the default containerd resolver will provide its authentication credentials if the server where the\n URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker\n publishes a public image with a manifest that directs one of the layers to be fetched from a web server\n they control and they trick a user or system into pulling the image, they can obtain the credentials used\n for pulling that image. In some cases, this may be the user's username and password for the registry. In\n other cases, this may be the credentials attached to the cloud virtual instance which can grant access to\n other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin\n (which can be used by Kubernetes), the ctr development tool, and other client programs that have\n explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and\n later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using\n cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker)\n are not affected. (CVE-2020-15157)\n\n - containerd is an industry-standard container runtime and is available as a daemon for Linux and Windows.\n In containerd before versions 1.3.9 and 1.4.3, the containerd-shim API is improperly exposed to host\n network containers. Access controls for the shim's API socket verified that the connecting process had an\n effective UID of 0, but did not otherwise restrict access to the abstract Unix domain socket. This would\n allow malicious containers running in the same network namespace as the shim, with an effective UID of 0\n but otherwise reduced privileges, to cause new processes to be run with elevated privileges. This\n vulnerability has been fixed in containerd 1.3.9 and 1.4.3. Users should update to these versions as soon\n as they are released. It should be noted that containers started with an old version of containerd-shim\n should be stopped and restarted, as running containers will continue to be vulnerable even after an\n upgrade. If you are not providing the ability for untrusted users to start containers in the same network\n namespace as the shim (typically the 'host' network namespace, for example with docker run --net=host or\n hostNetwork: true in a Kubernetes pod) and run with an effective UID of 0, you are not vulnerable to this\n issue. If you are running containers with a vulnerable configuration, you can deny access to all abstract\n sockets with AppArmor by adding a line similar to deny unix addr=@**, to your policy. It is best practice\n to run containers with a reduced set of privileges, with a non-zero UID, and with isolated namespaces. The\n containerd maintainers strongly advise against sharing namespaces with the host. Reducing the set of\n isolation mechanisms used for a container necessarily increases that container's privilege, regardless of\n what container runtime is used for running that container. (CVE-2020-15257)\n\n - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where\n pulling and extracting a specially-crafted container image can result in Unix file permission changes for\n existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner\n of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does\n not directly allow files to be read, modified, or executed without an additional cooperating process. This\n bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from\n trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially\n affected by this bug through policies and profiles that prevent containerd from interacting with specific\n files. (CVE-2021-32760)\n\n - containerd is an open source container runtime with an emphasis on simplicity, robustness and portability.\n A bug was found in containerd where container root directories and some plugins had insufficiently\n restricted permissions, allowing otherwise unprivileged Linux users to traverse directory contents and\n execute programs. When containers included executable programs with extended permission bits (such as\n setuid), unprivileged Linux users could discover and execute those programs. When the UID of an\n unprivileged Linux user on the host collided with the file owner or group inside a container, the\n unprivileged Linux user on the host could discover, read, and modify those files. This vulnerability has\n been fixed in containerd 1.4.11 and containerd 1.5.7. Users should update to these version when they are\n released and may restart containers or update directory permissions to mitigate the vulnerability. Users\n unable to update should limit access to the host to trusted users. Update directory permission on\n container bundles directories. (CVE-2021-41103)\n\n - Moby is an open-source project created by Docker to enable and accelerate software containerization. A bug\n was found in Moby (Docker Engine) prior to version 20.10.14 where containers were incorrectly started with\n non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling\n programs with inheritable file capabilities to elevate those capabilities to the permitted set during\n `execve(2)`. Normally, when executable programs have specified permitted file capabilities, otherwise\n unprivileged users and processes can execute those programs and gain the specified file capabilities up to\n the bounding set. Due to this bug, containers which included executable programs with inheritable file\n capabilities allowed otherwise unprivileged users and processes to additionally gain these inheritable\n file capabilities up to the container's bounding set. Containers which use Linux users and groups to\n perform privilege separation inside the container are most directly impacted. This bug did not affect the\n container security sandbox as the inheritable set never contained more capabilities than were included in\n the container's bounding set. This bug has been fixed in Moby (Docker Engine) 20.10.14. Running containers\n should be stopped, deleted, and recreated for the inheritable capabilities to be reset. This fix changes\n Moby (Docker Engine) behavior such that containers are started with a more typical Linux environment. As a\n workaround, the entry point of a container can be modified to use a utility like `capsh(1)` to drop\n inheritable capabilities prior to the primary process starting. (CVE-2022-24769)\n\nNote that Tenable Network Security has extracted the preceding description block directly from the EulerOS security\nadvisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional\nissues.\");\n # https://developer.huaweicloud.com/ict/en/site-euleros/euleros/security-advisories/EulerOS-SA-2022-1886\n script_set_attribute(attribute:\"see_also\", value:\"http://www.nessus.org/u?d8229852\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected docker-engine packages.\");\n script_set_cvss_base_vector(\"CVSS2#AV:L/AC:L/Au:N/C:C/I:C/A:C\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-41103\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"false\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/10/16\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2022/06/17\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2022/06/17\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:huawei:euleros:docker-engine-selinux\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:huawei:euleros:2.0\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Huawei Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2022 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/cpu\", \"Host/EulerOS/release\", \"Host/EulerOS/rpm-list\", \"Host/EulerOS/sp\");\n script_exclude_keys(\"Host/EulerOS/uvp_version\");\n\n exit(0);\n}\n\ninclude(\"rpm.inc\");\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\n\nvar release = get_kb_item(\"Host/EulerOS/release\");\nif (isnull(release) || release !~ \"^EulerOS\") audit(AUDIT_OS_NOT, \"EulerOS\");\nvar uvp = get_kb_item(\"Host/EulerOS/uvp_version\");\nif (release !~ \"^EulerOS release 2\\.0(\\D|$)\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP5\");\n\nvar sp = get_kb_item(\"Host/EulerOS/sp\");\nif (isnull(sp) || sp !~ \"^(5)$\") audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP5\");\n\nif (!empty_or_null(uvp)) audit(AUDIT_OS_NOT, \"EulerOS 2.0 SP5\", \"EulerOS UVP \" + uvp);\n\nif (!get_kb_item(\"Host/EulerOS/rpm-list\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\nvar cpu = get_kb_item(\"Host/cpu\");\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\" && \"aarch64\" >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, \"EulerOS\", cpu);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\") audit(AUDIT_ARCH_NOT, \"i686 / x86_64\", cpu);\n\nvar flag = 0;\n\nvar pkgs = [\n \"docker-engine-18.09.0.101-1.h52.22.9.eulerosv2r7\",\n \"docker-engine-selinux-18.09.0.101-1.h52.22.9.eulerosv2r7\"\n];\n\nforeach (var pkg in pkgs)\n if (rpm_check(release:\"EulerOS-2.0\", sp:\"5\", reference:pkg)) flag++;\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_HOLE,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n var tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, \"docker-engine\");\n}\n", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2022-05-19T14:35:58", "description": "The remote Redhat Enterprise Linux 7 / 8 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2020:5634 advisory.\n\n - atomic-openshift: cross-namespace owner references can trigger deletions of valid children (CVE-2019-3884)\n\n - containerd: credentials leak during image pull (CVE-2020-15157)\n\n - python-rsa: bleichenbacher timing oracle attack against RSA decryption (CVE-2020-25658)\n\n - golang: math/big: panic during recursive division of very large numbers (CVE-2020-28362)\n\n - kubernetes: Ceph RBD adminSecrets exposed in logs when loglevel >= 4 (CVE-2020-8566)\n\n - gogo/protobuf: plugin/unmarshal/unmarshal.go lacks certain index validation (CVE-2021-3121)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.", "cvss3": {"score": 8.6, "vector": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H"}, "published": "2021-02-24T00:00:00", "type": "nessus", "title": "RHEL 7 / 8 : OpenShift Container Platform 4.7.0 packages (RHSA-2020:5634)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2019-3884", "CVE-2020-15157", "CVE-2020-25658", "CVE-2020-28362", "CVE-2020-8566", "CVE-2021-3121"], "modified": "2022-05-17T00:00:00", "cpe": ["cpe:/o:redhat:enterprise_linux:7", "cpe:/o:redhat:enterprise_linux:8", "p-cpe:/a:redhat:enterprise_linux:cri-o", "p-cpe:/a:redhat:enterprise_linux:cri-tools", "p-cpe:/a:redhat:enterprise_linux:ignition-validate", "p-cpe:/a:redhat:enterprise_linux:openshift-hyperkube"], "id": "REDHAT-RHSA-2020-5634.NASL", "href": "https://www.tenable.com/plugins/nessus/146810", "sourceData": "##\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were\n# extracted from Red Hat Security Advisory RHSA-2020:5634. The text\n# itself is copyright (C) Red Hat, Inc.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(146810);\n script_version(\"1.8\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2022/05/17\");\n\n script_cve_id(\n \"CVE-2019-3884\",\n \"CVE-2020-8566\",\n \"CVE-2020-15157\",\n \"CVE-2020-25658\",\n \"CVE-2021-3121\"\n );\n script_bugtraq_id(107649);\n script_xref(name:\"RHSA\", value:\"2020:5634\");\n script_xref(name:\"IAVB\", value:\"2020-B-0071-S\");\n\n script_name(english:\"RHEL 7 / 8 : OpenShift Container Platform 4.7.0 packages (RHSA-2020:5634)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote Red Hat host is missing one or more security updates.\");\n script_set_attribute(attribute:\"description\", value:\n\"The remote Redhat Enterprise Linux 7 / 8 host has packages installed that are affected by multiple vulnerabilities as\nreferenced in the RHSA-2020:5634 advisory.\n\n - atomic-openshift: cross-namespace owner references can trigger deletions of valid children (CVE-2019-3884)\n\n - containerd: credentials leak during image pull (CVE-2020-15157)\n\n - python-rsa: bleichenbacher timing oracle attack against RSA decryption (CVE-2020-25658)\n\n - golang: math/big: panic during recursive division of very large numbers (CVE-2020-28362)\n\n - kubernetes: Ceph RBD adminSecrets exposed in logs when loglevel >= 4 (CVE-2020-8566)\n\n - gogo/protobuf: plugin/unmarshal/unmarshal.go lacks certain index validation (CVE-2021-3121)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version\nnumber.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://cwe.mitre.org/data/definitions/117.html\");\n script_set_attribute(attribute:\"see_also\", value:\"https://cwe.mitre.org/data/definitions/129.html\");\n script_set_attribute(attribute:\"see_also\", value:\"https://cwe.mitre.org/data/definitions/200.html\");\n script_set_attribute(attribute:\"see_also\", value:\"https://cwe.mitre.org/data/definitions/290.html\");\n script_set_attribute(attribute:\"see_also\", value:\"https://cwe.mitre.org/data/definitions/295.html\");\n script_set_attribute(attribute:\"see_also\", value:\"https://cwe.mitre.org/data/definitions/385.html\");\n script_set_attribute(attribute:\"see_also\", value:\"https://access.redhat.com/security/cve/CVE-2019-3884\");\n script_set_attribute(attribute:\"see_also\", value:\"https://access.redhat.com/security/cve/CVE-2020-8566\");\n script_set_attribute(attribute:\"see_also\", value:\"https://access.redhat.com/security/cve/CVE-2020-15157\");\n script_set_attribute(attribute:\"see_also\", value:\"https://access.redhat.com/security/cve/CVE-2020-25658\");\n script_set_attribute(attribute:\"see_also\", value:\"https://access.redhat.com/security/cve/CVE-2020-28362\");\n script_set_attribute(attribute:\"see_also\", value:\"https://access.redhat.com/security/cve/CVE-2021-3121\");\n script_set_attribute(attribute:\"see_also\", value:\"https://access.redhat.com/errata/RHSA-2020:5634\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.redhat.com/1693905\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.redhat.com/1886640\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.redhat.com/1888248\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.redhat.com/1889972\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.redhat.com/1897635\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.redhat.com/1921650\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected packages.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:L/Au:N/C:P/I:P/A:P\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-3121\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"false\");\n script_cwe_id(117, 129, 200, 290, 295, 385);\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2019/03/29\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2021/02/24\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2021/02/24\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:redhat:enterprise_linux:7\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:redhat:enterprise_linux:8\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:redhat:enterprise_linux:cri-o\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:redhat:enterprise_linux:cri-tools\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:redhat:enterprise_linux:ignition-validate\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:redhat:enterprise_linux:openshift-hyperkube\");\n script_set_attribute(attribute:\"stig_severity\", value:\"I\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Red Hat Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2021-2022 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\", \"redhat_repos.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/RedHat/release\", \"Host/RedHat/rpm-list\", \"Host/cpu\");\n\n exit(0);\n}\n\n\ninclude('audit.inc');\ninclude('global_settings.inc');\ninclude('misc_func.inc');\ninclude('rpm.inc');\ninclude('rhel.inc');\n\nif (!get_kb_item('Host/local_checks_enabled')) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nvar release = get_kb_item('Host/RedHat/release');\nif (isnull(release) || 'Red Hat' >!< release) audit(AUDIT_OS_NOT, 'Red Hat');\nvar os_ver = pregmatch(pattern: \"Red Hat Enterprise Linux.*release ([0-9]+(\\.[0-9]+)?)\", string:release);\nif (isnull(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, 'Red Hat');\nvar os_ver = os_ver[1];\nif (!rhel_check_release_list(operator: 'ge', os_version: os_ver, rhel_versions: ['7','8'])) audit(AUDIT_OS_NOT, 'Red Hat 7.x / 8.x', 'Red Hat ' + os_ver);\n\nif (!get_kb_item('Host/RedHat/rpm-list')) audit(AUDIT_PACKAGE_LIST_MISSING);\n\nvar cpu = get_kb_item('Host/cpu');\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif ('x86_64' >!< cpu && cpu !~ \"^i[3-6]86$\" && 's390' >!< cpu && 'aarch64' >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'Red Hat', cpu);\n\nvar repositories = {\n 'openshift_4_7_el7': [\n 'rhel-7-for-system-z-ose-4.7-rpms',\n 'rhel-7-server-ose-4.7-debug-rpms',\n 'rhel-7-server-ose-4.7-rpms',\n 'rhel-7-server-ose-4.7-source-rpms'\n ],\n 'openshift_4_7_el8': [\n 'rhocp-4.7-for-rhel-8-s390x-debug-rpms',\n 'rhocp-4.7-for-rhel-8-s390x-rpms',\n 'rhocp-4.7-for-rhel-8-s390x-source-rpms',\n 'rhocp-4.7-for-rhel-8-x86_64-debug-rpms',\n 'rhocp-4.7-for-rhel-8-x86_64-rpms',\n 'rhocp-4.7-for-rhel-8-x86_64-source-rpms'\n ]\n};\n\nvar repo_sets = rhel_get_valid_repo_sets(repositories:repositories);\nif(repo_sets == RHEL_REPOS_NO_OVERLAP_MESSAGE) audit(AUDIT_PACKAGE_LIST_MISSING, RHEL_REPO_AUDIT_PACKAGE_LIST_DETAILS);\n\nvar pkgs = [\n {'reference':'cri-o-1.20.0-0.rhaos4.7.git8921e00.el7.51', 'cpu':'x86_64', 'release':'7', 'rpm_spec_vers_cmp':TRUE, 'exists_check':'openshift', 'repo_list':['openshift_4_7_el7', 'openshift_4_7_el8']},\n {'reference':'cri-tools-1.18.0-3.el7', 'cpu':'x86_64', 'release':'7', 'rpm_spec_vers_cmp':TRUE, 'exists_check':'openshift', 'repo_list':['openshift_4_7_el7', 'openshift_4_7_el8']},\n {'reference':'openshift-hyperkube-4.7.0-202102060108.p0.git.97095.7271b90.el7', 'cpu':'x86_64', 'release':'7', 'rpm_spec_vers_cmp':TRUE, 'exists_check':'openshift', 'repo_list':['openshift_4_7_el7', 'openshift_4_7_el8']},\n {'reference':'cri-o-1.20.0-0.rhaos4.7.git8921e00.el8.51', 'cpu':'s390x', 'release':'8', 'rpm_spec_vers_cmp':TRUE, 'exists_check':'openshift', 'repo_list':['openshift_4_7_el8']},\n {'reference':'cri-o-1.20.0-0.rhaos4.7.git8921e00.el8.51', 'cpu':'x86_64', 'release':'8', 'rpm_spec_vers_cmp':TRUE, 'exists_check':'openshift', 'repo_list':['openshift_4_7_el8']},\n {'reference':'ignition-validate-1.20.0-0.rhaos4.7.git8921e00.el7.51', 'cpu':'x86_64', 'release':'8', 'rpm_spec_vers_cmp':TRUE, 'exists_check':'openshift', 'repo_list':['openshift_4_7_el8']},\n {'reference':'openshift-hyperkube-4.7.0-202102060108.p0.git.97095.7271b90.el8', 'cpu':'s390x', 'release':'8', 'rpm_spec_vers_cmp':TRUE, 'exists_check':'openshift', 'repo_list':['openshift_4_7_el8']},\n {'reference':'openshift-hyperkube-4.7.0-202102060108.p0.git.97095.7271b90.el8', 'cpu':'x86_64', 'release':'8', 'rpm_spec_vers_cmp':TRUE, 'exists_check':'openshift', 'repo_list':['openshift_4_7_el8']}\n];\n\nvar flag = 0;\nforeach package_array ( pkgs ) {\n var reference = NULL;\n var release = NULL;\n var sp = NULL;\n var cpu = NULL;\n var el_string = NULL;\n var rpm_spec_vers_cmp = NULL;\n var epoch = NULL;\n var allowmaj = NULL;\n var exists_check = NULL;\n var repo_list = NULL;\n if (!empty_or_null(package_array['repo_list'])) repo_list = package_array['repo_list'];\n if (!empty_or_null(package_array['reference'])) reference = package_array['reference'];\n if (!empty_or_null(package_array['release'])) release = 'RHEL' + package_array['release'];\n if (!empty_or_null(package_array['sp'])) sp = package_array['sp'];\n if (!empty_or_null(package_array['cpu'])) cpu = package_array['cpu'];\n if (!empty_or_null(package_array['el_string'])) el_string = package_array['el_string'];\n if (!empty_or_null(package_array['rpm_spec_vers_cmp'])) rpm_spec_vers_cmp = package_array['rpm_spec_vers_cmp'];\n if (!empty_or_null(package_array['epoch'])) epoch = package_array['epoch'];\n if (!empty_or_null(package_array['allowmaj'])) allowmaj = package_array['allowmaj'];\n if (!empty_or_null(package_array['exists_check'])) exists_check = package_array['exists_check'];\n if (reference &&\n release &&\n (rhel_decide_repo_check(repo_list:repo_list, repo_sets:repo_sets) || (!exists_check || rpm_exists(release:release, rpm:exists_check))) &&\n rpm_check(release:release, sp:sp, cpu:cpu, reference:reference, epoch:epoch, el_string:el_string, rpm_spec_vers_cmp:rpm_spec_vers_cmp, allowmaj:allowmaj)) flag++;\n}\n\nif (flag)\n{\n var extra = NULL;\n if (empty_or_null(repo_sets)) extra = rpm_report_get() + redhat_report_repo_caveat();\n else extra = rpm_report_get() + redhat_report_package_caveat();\n security_report_v4(\n port : 0,\n severity : SECURITY_HOLE,\n extra : extra\n );\n exit(0);\n}\nelse\n{\n var tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, 'cri-o / cri-tools / ignition-validate / openshift-hyperkube');\n}\n", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2022-03-12T23:20:37", "description": "The remote SUSE Linux SUSE15 host has packages installed that are affected by multiple vulnerabilities as referenced in the openSUSE-SU-2022:23018-1 advisory.\n\n - An information disclosure vulnerability was found in containers/podman in versions before 2.0.5. When using the deprecated Varlink API or the Docker-compatible REST API, if multiple containers are created in a short duration, the environment variables from the first container will get leaked into subsequent containers. An attacker who has control over the subsequent containers could use this flaw to gain access to sensitive information stored in such variables. (CVE-2020-14370)\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected. (CVE-2020-15157)\n\n - Rootless containers run with Podman, receive all traffic with a source IP address of 127.0.0.1 (including from remote hosts). This impacts containerized applications that trust localhost (127.0.01) connections by default and do not require authentication. This issue affects Podman 1.8.0 onwards. (CVE-2021-20199)\n\n - A deadlock vulnerability was found in 'github.com/containers/storage' in versions before 1.28.1. When a container image is processed, each layer is unpacked using `tar`. If one of those layers is not a valid `tar` archive this causes an error leading to an unexpected situation where the code indefinitely waits for the tar unpacked stream, which never finishes. An attacker could use this vulnerability to craft a malicious image, which when downloaded and stored by an application using containers/storage, would then cause a deadlock leading to a Denial of Service (DoS). (CVE-2021-20291)\n\n - An information disclosure flaw was found in Buildah, when building containers using chroot isolation.\n Running processes in container builds (e.g. Dockerfile RUN commands) can access environment variables from parent and grandparent processes. When run in a container in a CI/CD environment, environment variables may include sensitive information that was shared with the container in order to be used only by Buildah itself (e.g. container registry credentials). (CVE-2021-3602)\n\n - A flaw was found in podman. The `podman machine` function (used to create and manage Podman virtual machine containing a Podman process) spawns a `gvproxy` process on the host system. The `gvproxy` API is accessible on port 7777 on all IP addresses on the host. If that port is open on the host's firewall, an attacker can potentially use the `gvproxy` API to forward ports on the host to ports in the VM, making private services on the VM accessible to the network. This issue could be also used to interrupt the host's services by forwarding all ports to the VM. (CVE-2021-4024)\n\n - The OCI Distribution Spec project defines an API protocol to facilitate and standardize the distribution of content. In the OCI Distribution Specification version 1.0.0 and prior, the Content-Type header alone was used to determine the type of document during push and pull operations. Documents that contain both manifests and layers fields could be interpreted as either a manifest or an index in the absence of an accompanying Content-Type header. If a Content-Type header changed between two pulls of the same digest, a client may interpret the resulting content differently. The OCI Distribution Specification has been updated to require that a mediaType value present in a manifest or index match the Content-Type header used during the push and pull operations. Clients pulling from a registry may distrust the Content-Type header and reject an ambiguous document that contains both manifests and layers fields or manifests and config fields if they are unable to update to version 1.0.1 of the spec. (CVE-2021-41190)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.", "cvss3": {"score": 6.5, "vector": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L"}, "published": "2022-03-05T00:00:00", "type": "nessus", "title": "openSUSE 15 Security Update : conmon, libcontainers-common, libseccomp, podman (openSUSE-SU-2022:23018-1)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-14370", "CVE-2020-15157", "CVE-2021-3602", "CVE-2021-4024", "CVE-2021-20199", "CVE-2021-20291", "CVE-2021-41190"], "modified": "2022-03-05T00:00:00", "cpe": ["p-cpe:/a:novell:opensuse:conmon", "p-cpe:/a:novell:opensuse:libcontainers-common", "p-cpe:/a:novell:opensuse:libseccomp-devel", "p-cpe:/a:novell:opensuse:libseccomp-tools", "p-cpe:/a:novell:opensuse:libseccomp2", "p-cpe:/a:novell:opensuse:libseccomp2-32bit", "p-cpe:/a:novell:opensuse:podman", "p-cpe:/a:novell:opensuse:podman-cni-config", "cpe:/o:novell:opensuse:15.3"], "id": "OPENSUSE-2022-23018-1.NASL", "href": "https://www.tenable.com/plugins/nessus/158634", "sourceData": "#%NASL_MIN_LEVEL 70300\n##\n# (C) Tenable Network Security, Inc.\n#\n# The package checks in this plugin were extracted from\n# openSUSE Security Update openSUSE-SU-2022:23018-1. The text itself\n# is copyright (C) SUSE.\n##\n\ninclude('deprecated_nasl_level.inc');\ninclude('compat.inc');\n\nif (description)\n{\n script_id(158634);\n script_version(\"1.2\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2022/03/05\");\n\n script_cve_id(\n \"CVE-2020-14370\",\n \"CVE-2020-15157\",\n \"CVE-2021-3602\",\n \"CVE-2021-4024\",\n \"CVE-2021-20199\",\n \"CVE-2021-20291\",\n \"CVE-2021-41190\"\n );\n\n script_name(english:\"openSUSE 15 Security Update : conmon, libcontainers-common, libseccomp, podman (openSUSE-SU-2022:23018-1)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote SUSE host is missing one or more security updates.\");\n script_set_attribute(attribute:\"description\", value:\n\"The remote SUSE Linux SUSE15 host has packages installed that are affected by multiple vulnerabilities as referenced in\nthe openSUSE-SU-2022:23018-1 advisory.\n\n - An information disclosure vulnerability was found in containers/podman in versions before 2.0.5. When\n using the deprecated Varlink API or the Docker-compatible REST API, if multiple containers are created in\n a short duration, the environment variables from the first container will get leaked into subsequent\n containers. An attacker who has control over the subsequent containers could use this flaw to gain access\n to sensitive information stored in such variables. (CVE-2020-14370)\n\n - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking\n vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format\n includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the\n default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or\n later, the default containerd resolver will provide its authentication credentials if the server where the\n URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker\n publishes a public image with a manifest that directs one of the layers to be fetched from a web server\n they control and they trick a user or system into pulling the image, they can obtain the credentials used\n for pulling that image. In some cases, this may be the user's username and password for the registry. In\n other cases, this may be the credentials attached to the cloud virtual instance which can grant access to\n other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin\n (which can be used by Kubernetes), the ctr development tool, and other client programs that have\n explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and\n later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using\n cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.\n Other container runtimes built on top of containerd but not using the default resolver (such as Docker)\n are not affected. (CVE-2020-15157)\n\n - Rootless containers run with Podman, receive all traffic with a source IP address of 127.0.0.1 (including\n from remote hosts). This impacts containerized applications that trust localhost (127.0.01) connections by\n default and do not require authentication. This issue affects Podman 1.8.0 onwards. (CVE-2021-20199)\n\n - A deadlock vulnerability was found in 'github.com/containers/storage' in versions before 1.28.1. When a\n container image is processed, each layer is unpacked using `tar`. If one of those layers is not a valid\n `tar` archive this causes an error leading to an unexpected situation where the code indefinitely waits\n for the tar unpacked stream, which never finishes. An attacker could use this vulnerability to craft a\n malicious image, which when downloaded and stored by an application using containers/storage, would then\n cause a deadlock leading to a Denial of Service (DoS). (CVE-2021-20291)\n\n - An information disclosure flaw was found in Buildah, when building containers using chroot isolation.\n Running processes in container builds (e.g. Dockerfile RUN commands) can access environment variables from\n parent and grandparent processes. When run in a container in a CI/CD environment, environment variables\n may include sensitive information that was shared with the container in order to be used only by Buildah\n itself (e.g. container registry credentials). (CVE-2021-3602)\n\n - A flaw was found in podman. The `podman machine` function (used to create and manage Podman virtual\n machine containing a Podman process) spawns a `gvproxy` process on the host system. The `gvproxy` API is\n accessible on port 7777 on all IP addresses on the host. If that port is open on the host's firewall, an\n attacker can potentially use the `gvproxy` API to forward ports on the host to ports in the VM, making\n private services on the VM accessible to the network. This issue could be also used to interrupt the\n host's services by forwarding all ports to the VM. (CVE-2021-4024)\n\n - The OCI Distribution Spec project defines an API protocol to facilitate and standardize the distribution\n of content. In the OCI Distribution Specification version 1.0.0 and prior, the Content-Type header alone\n was used to determine the type of document during push and pull operations. Documents that contain both\n manifests and layers fields could be interpreted as either a manifest or an index in the absence of an\n accompanying Content-Type header. If a Content-Type header changed between two pulls of the same digest, a\n client may interpret the resulting content differently. The OCI Distribution Specification has been\n updated to require that a mediaType value present in a manifest or index match the Content-Type header\n used during the push and pull operations. Clients pulling from a registry may distrust the Content-Type\n header and reject an ambiguous document that contains both manifests and layers fields or manifests\n and config fields if they are unable to update to version 1.0.1 of the spec. (CVE-2021-41190)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version\nnumber.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.suse.com/1176804\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.suse.com/1177598\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.suse.com/1181640\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.suse.com/1182998\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.suse.com/1188520\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.suse.com/1188914\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.suse.com/1193166\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.suse.com/1193273\");\n # https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/5BA2TLW7O5ZURGQUAQUH4HD5SQYNDDZ6/\n script_set_attribute(attribute:\"see_also\", value:\"http://www.nessus.org/u?f8e88443\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.suse.com/security/cve/CVE-2020-14370\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.suse.com/security/cve/CVE-2020-15157\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.suse.com/security/cve/CVE-2021-20199\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.suse.com/security/cve/CVE-2021-20291\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.suse.com/security/cve/CVE-2021-3602\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.suse.com/security/cve/CVE-2021-4024\");\n script_set_attribute(attribute:\"see_also\", value:\"https://www.suse.com/security/cve/CVE-2021-41190\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected packages.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:P\");\n script_set_cvss_temporal_vector(\"CVSS2#E:U/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:U/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-4024\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"No known exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"false\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/09/22\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2022/03/04\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2022/03/05\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:conmon\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:libcontainers-common\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:libseccomp-devel\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:libseccomp-tools\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:libseccomp2\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:libseccomp2-32bit\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:podman\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:podman-cni-config\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:novell:opensuse:15.3\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"SuSE Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2022 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/cpu\", \"Host/SuSE/release\", \"Host/SuSE/rpm-list\");\n\n exit(0);\n}\n\n\ninclude('audit.inc');\ninclude('global_settings.inc');\ninclude('misc_func.inc');\ninclude('rpm.inc');\n\nif (!get_kb_item('Host/local_checks_enabled')) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nvar release = get_kb_item('Host/SuSE/release');\nif (isnull(release) || release =~ \"^(SLED|SLES)\") audit(AUDIT_OS_NOT, 'openSUSE');\nvar os_ver = pregmatch(pattern: \"^SUSE([\\d.]+)\", string:release);\nif (isnull(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, 'openSUSE');\nos_ver = os_ver[1];\nif (release !~ \"^(SUSE15\\.3)$\") audit(AUDIT_OS_RELEASE_NOT, 'openSUSE', '15.3', release);\nif (!get_kb_item(\"Host/SuSE/rpm-list\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\nvar cpu = get_kb_item('Host/cpu');\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif ('x86_64' >!< cpu && cpu !~ \"^i[3-6]86$\" && 's390' >!< cpu && 'aarch64' >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'openSUSE ' + os_ver, cpu);\n\nvar pkgs = [\n {'reference':'conmon-2.0.30-150300.8.3.1', 'release':'SUSE15.3', 'rpm_spec_vers_cmp':TRUE},\n {'reference':'libcontainers-common-20210626-150300.8.3.1', 'release':'SUSE15.3', 'rpm_spec_vers_cmp':TRUE},\n {'reference':'libseccomp-devel-2.5.3-150300.10.5.1', 'release':'SUSE15.3', 'rpm_spec_vers_cmp':TRUE},\n {'reference':'libseccomp-tools-2.5.3-150300.10.5.1', 'release':'SUSE15.3', 'rpm_spec_vers_cmp':TRUE},\n {'reference':'libseccomp2-2.5.3-150300.10.5.1', 'release':'SUSE15.3', 'rpm_spec_vers_cmp':TRUE},\n {'reference':'libseccomp2-32bit-2.5.3-150300.10.5.1', 'cpu':'x86_64', 'release':'SUSE15.3', 'rpm_spec_vers_cmp':TRUE},\n {'reference':'podman-3.4.4-150300.9.3.2', 'release':'SUSE15.3', 'rpm_spec_vers_cmp':TRUE},\n {'reference':'podman-cni-config-3.4.4-150300.9.3.2', 'release':'SUSE15.3', 'rpm_spec_vers_cmp':TRUE}\n];\n\nvar flag = 0;\nforeach package_array ( pkgs ) {\n var reference = NULL;\n var release = NULL;\n var cpu = NULL;\n var rpm_spec_vers_cmp = NULL;\n if (!empty_or_null(package_array['reference'])) reference = package_array['reference'];\n if (!empty_or_null(package_array['release'])) release = package_array['release'];\n if (!empty_or_null(package_array['cpu'])) cpu = package_array['cpu'];\n if (!empty_or_null(package_array['rpm_spec_vers_cmp'])) rpm_spec_vers_cmp = package_array['rpm_spec_vers_cmp'];\n if (reference && release) {\n if (rpm_check(release:release, cpu:cpu, reference:reference, rpm_spec_vers_cmp:rpm_spec_vers_cmp)) flag++;\n }\n}\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_WARNING,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n var tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, 'conmon / libcontainers-common / libseccomp-devel / libseccomp-tools / etc');\n}\n", "cvss": {"score": 6.4, "vector": "AV:N/AC:L/Au:N/C:P/I:N/A:P"}}], "ubuntucve": [{"lastseen": "2022-08-04T13:25:39", "description": "In containerd (an industry-standard container runtime) before version\n1.2.14 there is a credential leaking vulnerability. If a container image\nmanifest in the OCI Image format or Docker Image V2 Schema 2 format\nincludes a URL for the location of a specific image layer (otherwise known\nas a \u201cforeign layer\u201d), the default containerd resolver will follow that URL\nto attempt to download it. In v1.2.x but not 1.3.0 or later, the default\ncontainerd resolver will provide its authentication credentials if the\nserver where the URL is located presents an HTTP 401 status code along with\nregistry-specific HTTP headers. If an attacker publishes a public image\nwith a manifest that directs one of the layers to be fetched from a web\nserver they control and they trick a user or system into pulling the image,\nthey can obtain the credentials used for pulling that image. In some cases,\nthis may be the user's username and password for the registry. In other\ncases, this may be the credentials attached to the cloud virtual instance\nwhich can grant access to other cloud resources in the account. The default\ncontainerd resolver is used by the cri-containerd plugin (which can be used\nby Kubernetes), the ctr development tool, and other client programs that\nhave explicitly linked against it. This vulnerability has been fixed in\ncontainerd 1.2.14. containerd 1.3 and later are not affected. If you are\nusing containerd 1.3 or later, you are not affected. If you are using\ncri-containerd in the 1.2 series or prior, you should ensure you only pull\nimages from trusted sources. Other container runtimes built on top of\ncontainerd but not using the default resolver (such as Docker) are not\naffected.", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "baseScore": 6.1, "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 4.0}, "published": "2020-10-15T00:00:00", "type": "ubuntucve", "title": "CVE-2020-15157", "bulletinFamily": "info", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 2.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2020-10-15T00:00:00", "id": "UB:CVE-2020-15157", "href": "https://ubuntu.com/security/CVE-2020-15157", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}], "ubuntu": [{"lastseen": "2022-01-04T11:09:31", "description": "It was discovered that containerd could be made to expose sensitive \ninformation when processing URLs in container image manifests. A \nremote attacker could use this to trick the user and obtain the \nuser's registry credentials.\n", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 6.1, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "userInteraction": "REQUIRED", "version": "3.1"}, "impactScore": 4.0}, "published": "2020-10-15T00:00:00", "type": "ubuntu", "title": "containerd vulnerability", "bulletinFamily": "unix", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 2.9, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2020-10-15T00:00:00", "id": "USN-4589-1", "href": "https://ubuntu.com/security/notices/USN-4589-1", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}], "photon": [{"lastseen": "2021-11-03T20:57:40", "description": "An update of {'containerd'} packages of Photon OS has been released.\n", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 6.1, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "userInteraction": "REQUIRED", "version": "3.1"}, "impactScore": 4.0}, "published": "2020-10-23T00:00:00", "type": "photon", "title": "Home\nDownload Photon OS\nUser Documentation\nFAQ\nSecurity Advisories\nRelated Information\n\nLightwave - PHSA-2020-2.0-0292", "bulletinFamily": "unix", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 2.9, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2020-10-23T00:00:00", "id": "PHSA-2020-2.0-0292", "href": "https://github.com/vmware/photon/wiki/Security-Updates-2-292", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}, {"lastseen": "2021-11-04T02:56:50", "description": "An update of {'oniguruma', 'containerd', 'apache-ant', 'python3'} packages of Photon OS has been released.\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "NONE", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "HIGH", "baseScore": 7.5, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 3.6}, "published": "2020-10-24T00:00:00", "type": "photon", "title": "Home\nDownload Photon OS\nUser Documentation\nFAQ\nSecurity Advisories\nRelated Information\n\nLightwave - PHSA-2020-3.0-0155", "bulletinFamily": "unix", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "PARTIAL", "baseScore": 6.4, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 4.9, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-11979", "CVE-2020-15157", "CVE-2020-26116", "CVE-2020-26159"], "modified": "2020-10-24T00:00:00", "id": "PHSA-2020-3.0-0155", "href": "https://github.com/vmware/photon/wiki/Security-Updates-3.0-155", "cvss": {"score": 6.4, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:N"}}, {"lastseen": "2022-05-12T18:47:27", "description": "Updates of ['containerd', 'apache-ant', 'python3', 'oniguruma'] packages of Photon OS have been released.\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "NONE", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 7.5, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 3.6}, "published": "2020-10-24T00:00:00", "type": "photon", "title": "Important Photon OS Security Update - PHSA-2020-0155", "bulletinFamily": "unix", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "PARTIAL", "baseScore": 6.4, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 4.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-11979", "CVE-2020-15157", "CVE-2020-26116", "CVE-2020-26159"], "modified": "2020-10-24T00:00:00", "id": "PHSA-2020-0155", "href": "https://github.com/vmware/photon/wiki/Security-Update-3.0-155", "cvss": {"score": 6.4, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:N"}}, {"lastseen": "2022-08-15T19:03:12", "description": "Updates of ['linux-aws', 'linux-secure', 'linux-esx', 'linux', 'containerd'] packages of Photon OS have been released.\n", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "ADJACENT_NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2020-10-16T00:00:00", "type": "photon", "title": "Important Photon OS Security Update - PHSA-2020-0292", "bulletinFamily": "unix", "cvss2": {"severity": "HIGH", "exploitabilityScore": 6.8, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "PARTIAL", "availabilityImpact": "COMPLETE", "integrityImpact": "PARTIAL", "baseScore": 7.5, "vectorString": "AV:N/AC:M/Au:S/C:P/I:P/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "impactScore": 8.5, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-12351", "CVE-2020-12352", "CVE-2020-15157", "CVE-2020-25643", "CVE-2020-28915"], "modified": "2020-10-16T00:00:00", "id": "PHSA-2020-0292", "href": "https://github.com/vmware/photon/wiki/Security-Update-2.0-292", "cvss": {"score": 7.5, "vector": "AV:N/AC:M/Au:S/C:P/I:P/A:C"}}], "amazon": [{"lastseen": "2022-01-12T02:29:47", "description": "**Issue Overview:**\n\nA flaw was found in containerd. Credentials may be leaked during an image pull. (CVE-2020-15157)\n\n \n**Affected Packages:** \n\n\ncontainerd\n\n \n**Issue Correction:** \nRun _yum update containerd_ to update your system. \n\n\n \n\n\n**New Packages:**\n \n \n src: \n \u00a0\u00a0\u00a0 containerd-1.3.2-1.3.amzn1.src \n \n x86_64: \n \u00a0\u00a0\u00a0 containerd-debuginfo-1.3.2-1.3.amzn1.x86_64 \n \u00a0\u00a0\u00a0 containerd-stress-1.3.2-1.3.amzn1.x86_64 \n \u00a0\u00a0\u00a0 containerd-1.3.2-1.3.amzn1.x86_64 \n \n \n", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 6.1, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "userInteraction": "REQUIRED", "version": "3.1"}, "impactScore": 4.0}, "published": "2021-12-28T23:54:00", "type": "amazon", "title": "Medium: containerd", "bulletinFamily": "unix", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 2.9, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2021-12-29T00:02:00", "id": "ALAS-2021-1555", "href": "https://alas.aws.amazon.com/ALAS-2021-1555.html", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}], "mageia": [{"lastseen": "2022-04-18T11:19:34", "description": "It was discovered that Docker could be made to expose sensitive information when processing URLs in container image manifests. A remote attacker could use this to trick the user and obtain the user's registry credentials (CVE-2020-15157). \n", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "baseScore": 6.1, "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 4.0}, "published": "2020-11-09T14:48:43", "type": "mageia", "title": "Updated docker packages fix a security vulnerability\n", "bulletinFamily": "unix", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 2.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2020-11-09T14:48:43", "id": "MGASA-2020-0406", "href": "https://advisories.mageia.org/MGASA-2020-0406.html", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}], "cve": [{"lastseen": "2022-03-23T13:33:57", "description": "In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a \u201cforeign layer\u201d), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources. Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected.", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "baseScore": 6.1, "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 4.0}, "published": "2020-10-16T17:15:00", "type": "cve", "title": "CVE-2020-15157", "cwe": ["CWE-522"], "bulletinFamily": "NVD", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 2.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2021-11-18T16:16:00", "cpe": ["cpe:/o:canonical:ubuntu_linux:20.04", "cpe:/o:canonical:ubuntu_linux:18.04", "cpe:/o:debian:debian_linux:10.0", "cpe:/o:canonical:ubuntu_linux:16.04", "cpe:/a:linuxfoundation:containerd:1.3.0"], "id": "CVE-2020-15157", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-15157", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}, "cpe23": ["cpe:2.3:o:canonical:ubuntu_linux:20.04:*:*:*:lts:*:*:*", "cpe:2.3:a:linuxfoundation:containerd:1.3.0:rc2:*:*:*:*:*:*", "cpe:2.3:o:debian:debian_linux:10.0:*:*:*:*:*:*:*", "cpe:2.3:a:linuxfoundation:containerd:1.3.0:rc1:*:*:*:*:*:*", "cpe:2.3:a:linuxfoundation:containerd:1.3.0:beta2:*:*:*:*:*:*", "cpe:2.3:a:linuxfoundation:containerd:1.3.0:beta0:*:*:*:*:*:*", "cpe:2.3:o:canonical:ubuntu_linux:18.04:*:*:*:lts:*:*:*", "cpe:2.3:a:linuxfoundation:containerd:1.3.0:rc3:*:*:*:*:*:*", "cpe:2.3:a:linuxfoundation:containerd:1.3.0:rc0:*:*:*:*:*:*", "cpe:2.3:a:linuxfoundation:containerd:1.3.0:beta1:*:*:*:*:*:*", "cpe:2.3:o:canonical:ubuntu_linux:16.04:*:*:*:lts:*:*:*", "cpe:2.3:a:linuxfoundation:containerd:1.3.0:-:*:*:*:*:*:*"]}], "oraclelinux": [{"lastseen": "2021-07-28T14:24:51", "description": "[1.2.14-1.0.1]\n- BUILDINFO: commit=259ae80da592d4f6b5e3cdc87202d36bc86a3579\n- Addresses CVE-2020-15157\n[1.2.14-1.0.0]\n- Added Oracle specific build files", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 6.1, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "userInteraction": "REQUIRED", "version": "3.1"}, "impactScore": 4.0}, "published": "2020-11-02T00:00:00", "type": "oraclelinux", "title": "containerd security update", "bulletinFamily": "unix", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 2.9, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2020-11-02T00:00:00", "id": "ELSA-2020-5906", "href": "http://linux.oracle.com/errata/ELSA-2020-5906.html", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}, {"lastseen": "2021-07-28T14:24:25", "description": "docker-engine\n[19.03.11-6]\n- Fix for CVE-2020-15157\n[19.03.11-5]\n- Bugfix for 'docker images [name]' not working on docker 19.03.11-ol\n- Address CVE-2020-16845\n[19.03.11-4]\n- added patch for registry list\n[19.03.11-3]\n- update to 19.03.11 for CVE-2020-13401\n[19.03.1-1.0.0]\n- update to 19.03.1\n[19.03-0.0.1]\n- update to 19.03\n[18.09.1-1.0.6]\n- disable kmem accounting for UEKR4\n[18.09.1-1.0.5]\n- apply e4931e664feac6fa8846f3f04268a0cc98822549, fixes CVE-2019-5736\n[18.09.1-1.0.4]\n- fix authentication error when using docker hub and using --default-registry\n[18.09.1-1.0.3]\n- fix authentication errors when using docker hub\n[18.09.1-1.0.2]\n- use epoch in container-selinux dependency\n[18.09.1-1.0.1]\n- fix 'docker cp doesn't work for btrfs' (OLM-158)\n- update build to Go 1.10.8\n[18.09.1-1.0.0]\n- update to 18.09.1\n[18.09-1.0.0]\n- rename back to docker-engine, rename dockerd-ce to dockerd and stop\n using alternatives\n[18.09-0.0.1]\n- merge docker-engine.spec changes by Oracle into docker-ce.spec from upstream\n 18.09 branch\n[18.03.1.ol-0.0.7]\n- fix [orabug 28452214] and [orabug 28461404]\n[18.03.1.ol-0.0.6]\n- obsolete/provide the docker package [orabug 28216396]\n- Fix docker plugin reference resolution [orabug 28376247]\n[18.03.1.ol-1.0.4]\n- Fixed issue where RPM overwrites config files\n[17.12.0.ol-1.0.1]\n- Update docker-engine package for upstream 17.12.0\n[17.09.1.ol-1.0.2]\n- Update docker-engine package for upstream 17.09.1\n[17.06.2.ol-1.0.1]\n- Update docker-engine package for upstream 17.06.2 [orabug 26673768]\n- Migrate to new 'ol'-based versioning\n- add docker-storage-config utility\n[17.03.1-ce-3.0.1]\n- Update docker-engine package for upstream 17.03.1\n- Enable configuration of Docker daemon via sysconfig [orabug 21804877]\n- Require UEK4 for docker 1.9 [orabug 22235639 22235645]\n- Add docker.conf for prelink [orabug 25147708]\n- Update oracle linux selinux policy to match upstream [orabug 25653794]\n- Use dockerd instead of docker daemon as it is deprecated [orabug 25653794]\ndocker-cli\n[19.03.11-6]\n- Fix for CVE-2020-15157\n[19.03.11-5]\n- Bugfix for 'docker images [name]' not working on docker 19.03.11-ol\n- Address CVE-2020-16845\n[19.03.11-4]\n- added patch for registry list\n[19.03.11-3]\n- update to 19.03.11 for CVE-2020-13401\n[19.03.1-1.0.0]\n- update to 19.03.1\n[19.03-0.0.1]\n- update to 19.03\n[18.09.1-1.0.6]\n- disable kmem accounting for UEKR4\n[18.09.1-1.0.5]\n- apply e4931e664feac6fa8846f3f04268a0cc98822549, fixes CVE-2019-5736\n[18.09.1-1.0.4]\n- fix authentication error when using docker hub and using --default-registry\n[18.09.1-1.0.3]\n- fix authentication errors when using docker hub\n[18.09-1.0.0]\n- rename to docker-cli\n[18.09-0.0.1]\n- merge docker-engine.spec changes by Oracle into docker-ce-cli.spec from\n upstream 18.09 branch", "cvss3": {"exploitabilityScore": 1.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "CHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.6, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H", "userInteraction": "REQUIRED", "version": "3.1"}, "impactScore": 6.0}, "published": "2020-10-28T00:00:00", "type": "oraclelinux", "title": "docker-engine docker-cli security update", "bulletinFamily": "unix", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2019-5736", "CVE-2020-13401", "CVE-2020-15157", "CVE-2020-16845"], "modified": "2020-10-28T00:00:00", "id": "ELSA-2020-5900", "href": "http://linux.oracle.com/errata/ELSA-2020-5900.html", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2021-07-28T14:24:42", "description": "docker-cli\n[19.03.11-7]\n- Fix for CVE-2020-15257\n[19.03.11-6]\n- Fix for CVE-2020-15157\n[19.03.11-5]\n- Bugfix for 'docker images [name]' not working on docker 19.03.11-ol\n- Address CVE-2020-16845\n[19.03.11-4]\n- added patch for registry list\n[19.03.11-3]\n- update to 19.03.11 for CVE-2020-13401\n[19.03.1-1.0.0]\n- update to 19.03.1\n[19.03-0.0.1]\n- update to 19.03\n[18.09.1-1.0.6]\n- disable kmem accounting for UEKR4\n[18.09.1-1.0.5]\n- apply e4931e664feac6fa8846f3f04268a0cc98822549, fixes CVE-2019-5736\n[18.09.1-1.0.4]\n- fix authentication error when using docker hub and using --default-registry\n[18.09.1-1.0.3]\n- fix authentication errors when using docker hub\n[18.09-1.0.0]\n- rename to docker-cli\n[18.09-0.0.1]\n- merge docker-engine.spec changes by Oracle into docker-ce-cli.spec from\n upstream 18.09 branch\ndocker-engine\n[19.03.11-7]\n- Fix for CVE-2020-15257\n[19.03.11-6]\n- Fix for CVE-2020-15157\n[19.03.11-5]\n- Bugfix for 'docker images [name]' not working on docker 19.03.11-ol\n- Address CVE-2020-16845\n[19.03.11-4]\n- added patch for registry list\n[19.03.11-3]\n- update to 19.03.11 for CVE-2020-13401\n[19.03.1-1.0.0]\n- update to 19.03.1\n[19.03-0.0.1]\n- update to 19.03\n[18.09.1-1.0.6]\n- disable kmem accounting for UEKR4\n[18.09.1-1.0.5]\n- apply e4931e664feac6fa8846f3f04268a0cc98822549, fixes CVE-2019-5736\n[18.09.1-1.0.4]\n- fix authentication error when using docker hub and using --default-registry\n[18.09.1-1.0.3]\n- fix authentication errors when using docker hub\n[18.09.1-1.0.2]\n- use epoch in container-selinux dependency\n[18.09.1-1.0.1]\n- fix 'docker cp doesn't work for btrfs' (OLM-158)\n- update build to Go 1.10.8\n[18.09.1-1.0.0]\n- update to 18.09.1\n[18.09-1.0.0]\n- rename back to docker-engine, rename dockerd-ce to dockerd and stop\n using alternatives\n[18.09-0.0.1]\n- merge docker-engine.spec changes by Oracle into docker-ce.spec from upstream\n 18.09 branch\n[18.03.1.ol-0.0.7]\n- fix [orabug 28452214] and [orabug 28461404]\n[18.03.1.ol-0.0.6]\n- obsolete/provide the docker package [orabug 28216396]\n- Fix docker plugin reference resolution [orabug 28376247]\n[18.03.1.ol-1.0.4]\n- Fixed issue where RPM overwrites config files\n[17.12.0.ol-1.0.1]\n- Update docker-engine package for upstream 17.12.0\n[17.09.1.ol-1.0.2]\n- Update docker-engine package for upstream 17.09.1\n[17.06.2.ol-1.0.1]\n- Update docker-engine package for upstream 17.06.2 [orabug 26673768]\n- Migrate to new 'ol'-based versioning\n- add docker-storage-config utility\n[17.03.1-ce-3.0.1]\n- Update docker-engine package for upstream 17.03.1\n- Enable configuration of Docker daemon via sysconfig [orabug 21804877]\n- Require UEK4 for docker 1.9 [orabug 22235639 22235645]\n- Add docker.conf for prelink [orabug 25147708]\n- Update oracle linux selinux policy to match upstream [orabug 25653794]\n- Use dockerd instead of docker daemon as it is deprecated [orabug 25653794]", "cvss3": {"exploitabilityScore": 1.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "CHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.6, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H", "userInteraction": "REQUIRED", "version": "3.1"}, "impactScore": 6.0}, "published": "2020-12-05T00:00:00", "type": "oraclelinux", "title": "docker-cli docker-engine security update", "bulletinFamily": "unix", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2019-5736", "CVE-2020-13401", "CVE-2020-15157", "CVE-2020-15257", "CVE-2020-16845"], "modified": "2020-12-05T00:00:00", "id": "ELSA-2020-5966", "href": "http://linux.oracle.com/errata/ELSA-2020-5966.html", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}], "veracode": [{"lastseen": "2022-07-26T16:56:44", "description": "containerd is vulnerable to information disclosure. The containerd resolver sends the authentication credentials when it follows a URL to attempt to download a specific image layer. An attacker is able to exploit this behavior to obtain the authentication credentials by publishing a public image with a manifest that redirects the layers to a third-party address.\n", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "baseScore": 6.1, "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 4.0}, "published": "2020-10-18T01:59:36", "type": "veracode", "title": "Information Disclosure", "bulletinFamily": "software", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 2.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2021-11-18T18:11:40", "id": "VERACODE:27611", "href": "https://sca.analysiscenter.veracode.com/vulnerability-database/security/1/1/sid-27611/summary", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}], "osv": [{"lastseen": "2022-05-11T21:07:25", "description": "## Impact\n\nIf a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a \u201cforeign layer\u201d), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers.\n\nIf an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account.\n\nThe default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it.\n\nThis vulnerability has been rated by the containerd maintainers as medium, with a CVSS score of 6.1 and a vector string of CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N.\n\n## Patches\n\nThis vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected.\n\n## Workarounds\n\nIf you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources. Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected.\n\n## Credits\n\nThe containerd maintainers would like to thank Brad Geesaman, Josh Larsen, Ian Coldwater, Duffie Cooley, and Rory McCune for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/master/SECURITY.md).", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "baseScore": 6.1, "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 4.0}, "published": "2022-02-11T23:27:39", "type": "osv", "title": "containerd v1.2.x can be coerced into leaking credentials during image pull", "bulletinFamily": "software", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 2.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2022-02-11T23:27:39", "id": "OSV:GHSA-742W-89GC-8M9C", "href": "https://osv.dev/vulnerability/GHSA-742w-89gc-8m9c", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}, {"lastseen": "2022-08-10T07:19:51", "description": "\nMultiple security issues were discovered in Docker, a Linux container\nruntime, which could result in denial of service, an information leak\nor privilege escalation.\n\n\nFor the stable distribution (buster), these problems have been fixed in\nversion 18.09.1+dfsg1-7.1+deb10u3.\n\n\nWe recommend that you upgrade your docker.io packages.\n\n\nFor the detailed security status of docker.io please refer to\nits security tracker page at:\n[\\\nhttps://security-tracker.debian.org/tracker/docker.io](https://security-tracker.debian.org/tracker/docker.io)\n\n\n", "cvss3": {"exploitabilityScore": 2.3, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "attackComplexity": "LOW", "scope": "CHANGED", "attackVector": "ADJACENT_NETWORK", "availabilityImpact": "NONE", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 6.8, "vectorString": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 4.0}, "published": "2021-02-27T00:00:00", "type": "osv", "title": "docker.io - security update", "bulletinFamily": "software", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "NONE", "availabilityImpact": "PARTIAL", "integrityImpact": "NONE", "baseScore": 4.3, "vectorString": "AV:N/AC:M/Au:N/C:N/I:N/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 2.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157", "CVE-2020-15257", "CVE-2021-21284", "CVE-2021-21285"], "modified": "2022-08-10T07:19:45", "id": "OSV:DSA-4865-1", "href": "https://osv.dev/vulnerability/DSA-4865-1", "cvss": {"score": 4.3, "vector": "AV:N/AC:M/Au:N/C:N/I:N/A:P"}}], "redhatcve": [{"lastseen": "2022-08-13T11:11:17", "description": "A flaw was found in containerd. Credentials may be leaked during an image pull.\n", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "baseScore": 6.1, "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 4.0}, "published": "2020-10-21T15:55:41", "type": "redhatcve", "title": "CVE-2020-15157", "bulletinFamily": "info", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 2.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2022-08-13T10:29:53", "id": "RH:CVE-2020-15157", "href": "https://access.redhat.com/security/cve/cve-2020-15157", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}], "debiancve": [{"lastseen": "2022-08-15T18:52:40", "description": "In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a \u201cforeign layer\u201d), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources. Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected.", "cvss3": {"exploitabilityScore": 1.6, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "NONE", "baseScore": 6.1, "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 4.0}, "published": "2020-10-16T17:15:00", "type": "debiancve", "title": "CVE-2020-15157", "bulletinFamily": "info", "cvss2": {"severity": "LOW", "exploitabilityScore": 4.9, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "HIGH", "confidentialityImpact": "PARTIAL", "availabilityImpact": "NONE", "integrityImpact": "NONE", "baseScore": 2.6, "vectorString": "AV:N/AC:H/Au:N/C:P/I:N/A:N", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 2.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157"], "modified": "2020-10-16T17:15:00", "id": "DEBIANCVE:CVE-2020-15157", "href": "https://security-tracker.debian.org/tracker/CVE-2020-15157", "cvss": {"score": 2.6, "vector": "AV:N/AC:H/Au:N/C:P/I:N/A:N"}}], "threatpost": [{"lastseen": "2022-05-03T11:14:04", "description": "Containers are self-contained pods representing complete, portable application environments. They contain everything an application needs to run, including binaries, libraries, configuration files and dependencies (Docker and Amazon Elastic, for instance, are two of the more well-known offerings).\n\nMultiple containers can run on a shared infrastructure and use the same operating system kernel, but they\u2019re abstracted from that layer and have little contact with the underlying hosting resources (which could be, for example, a public cloud instance).\n\n_[**Editor\u2019s Note:** This article was originally published in the free Threatpost eBook \u201c[Cloud Security: The Forecast for 2022.](<https://bit.ly/3Jy6Bfs>)\u201d In it we explore organizations\u2019 top risks and challenges, best practices for defense, and advice for security success in such a dynamic computing environment, including handy checklists. Please download the [FREE eBook](<https://bit.ly/3Jy6Bfs>) for the full story]_\n\nThe benefits of running cloud-based containers are varied and include the ability to easily spin applications up and down for users (think \u201cwrite once, run everywhere\u201d \u2013 a big boon for companies managing pandemic-related remote footprints). They also offer major infrastructure cost savings compared with managing applications on owned-and-operated servers or on virtual machines. They also provide increased agility by supporting DevOps goals.\n\nContainers are also easy to manage, thanks to orchestration engines such as Kubernetes. Admins can use orchestration to manage containerized apps and services at scale in a centralized fashion, pushing out automatic updates, isolating any failing containers and the like.\n\nAs a result, container adoption is at an all-time high, with companies of all sizes looking to embrace the technology. In just one example, a survey from the Cloud Native Computing Foundation (CNCF) found that 83 percent of respondents were using Kubernetes in production in 2020, up from 78 percent the previous year and just 58 percent in 2018.\n\nAs adoption increases, so does the interest of cybercriminals. A June Red Hat survey found that a whopping 94 percent of respondents had suffered a Kubernetes security incident over the previous 12 months.\n\n\u201cKubernetes attacks are actually quite common, especially given how popular the container orchestration software is,\u201d said Trevor Morgan, product manager at comforte AG. \u201cThe array of threats to Kubernetes environments is quite broad.\u201d\n\nHe added, \u201cWhether they are state-sponsored agents trying to undermine other political entities or are part of a gang or individual effort to steal for financial gain, the common denominator is always sensitive information. If threat actors can get to sensitive information, they can leverage it to build more complete data subject profiles (to then use for nefarious purposes), to hold information for ransom, and to weaponize it in any number of ways. And don\u2019t underestimate the sheer value of chaos that this all can create. They thrive in environments of fear and chaos.\u201d\n\n## **Containers in Cyberattack Sights**\n\nAs an example of how popular targeting vulnerable cloud infrastructure has become, Akamai security researcher Larry Cashdollar recently set up a simple Docker container honeypot, just to see what kind of notice it might attract from the wider web\u2019s cadre of cyberattackers. The results were head-turning: The honeypot was used for four different criminal campaigns in the span of 24 hours.\n\nCashdollar had implemented SSH protocol for encryption and implemented a \u201cguessable\u201d root password. Since it was running a standard cloud container configuration, it wouldn\u2019t stand out on the web as an obvious honeypot, he explained. Instead, it would simply look like a vulnerable cloud instance.\n\nThe attacks were varied in terms of their goals: One campaign tried to use the container as a proxy to tap into Twitch streams or access other services, another attempted a botnet infection, another performed cryptomining, and the last effort involved running a work-from-home scam.\n\nAs these examples show, \u201cprofit is still the primary motivation for cybercriminals targeting containers,\u201d explained Mark Nunnikhoven, distinguished cloud strategist at Lacework. \u201cMalicious actors strive to retrieve access to resources or data they can convert into a profit. Resources like CPU time and bandwidth can be resold to other criminals for underground services, or even can be used to mine cryptocurrency directly. Data can always be sold or ransomed. These motivations don\u2019t change in an environment that heavily leverages containers.\u201d\n\n## **Misconfiguration: The Most-Common Container Risk Factor**\n\nContainer technology, like other types of infrastructure, can be compromised in a number of different ways \u2013 however, misconfiguration reigns atop the initial-access leaderboard. According to a recent Gartner analysis, through 2025, more than 99 percent of cloud breaches will have a root cause of customer misconfigurations or mistakes.\n\n\u201cContainers are often deployed in sets and in very dynamic environments,\u201d Nunnikhoven explained. \u201cThe misconfiguration of access, networking and other settings can lead to an opportunity for cybercriminals.\u201d\n\nTrevor Morgan, product manager at comforte AG, noted that companies, especially smaller companies, are generally using default configuration settings vs. more sophisticated and granular configuration capabilities: \u201cBasic misconfigurations or accepting default settings that are far less secure than customized settings.\u201d\n\nThat can lead to big (and expensive) problems. For instance, last June the \u201cSiloscape\u201d malware was discovered, which is the first known malware to target Windows containers. It breaks out of Kubernetes clusters to plant backdoors, raid nodes for credentials or even hijack an entire database hosted in a cluster. Its main purpose, Palo Alto Networks Unit 42 researchers said, is opening \u201ca backdoor into poorly configured Kubernetes clusters in order to run malicious containers.\u201d\n\nConfiguration woes often extend beyond the containers themselves. Last July, for example, Kubernetes clusters were seen being attacked via misconfigured Argo Workflows instances.\n\nArgo Workflows is an open-source, container-native workflow engine for orchestrating parallel jobs on Kubernetes \u2013 to speed up processing time for compute-intensive jobs like machine learning and big-data processing. Malware operators were taking advantage of publicly available dashboards that didn\u2019t require authentication for outside users, according to an analysis from Intezer, in order to drop cryptominers into the cloud.\n\n## Compromised Container Images\n\nNunnikhoven noted that beyond misconfiguration, compromised images or layers are the next most important risk to containers. Images are pre-made, static files with executable code that can create a container on a computing system. They can be made available via open-source repositories for easy deployment.\n\n\u201cLacework Labs has seen several occurrences of cybercriminals compromising containers either through malware implants or cryptomining programs being pre-installed in the image,\u201d he explained. \u201cWhen a team deploys those images, the attacker then gains access to the resources of the victim.\u201d\n\nA related case involves a bug found in 2020 in the Containerd runtime tool, which manages the complete container lifecycle of its host system. The bug (CVE-2020-15157) was located in the container image-pulling process, according to Gal Singer, researcher at Aqua Security. Adversaries could exploit it by building dedicated container images designed to steal the host\u2019s token when they were pulled into a project. Then, they could use the token to take over a cloud project.\n\nSimilarly, a denial-of-service issue in one of the Go libraries that Kubernetes is based on (CVE-2021-20291) was found to be triggered by placing a malicious image inside a registry. The DoS condition was created when that image was pulled from the registry by an unsuspecting user.\n\n## Bug Parade\n\nThe next problem area arises from vulnerabilities, both known and zero-day issues. Several container bugs were identified in 2021, but perhaps the most disconcerting was \u201cAzurescape.\u201d\n\nUnit 42 researchers discovered a chain of exploits that could allow a malicious Azure user to infiltrate other customers\u2019 cloud instances within Microsoft\u2019s multitenant container-as-a-service offering. This critical crossaccount container takeover was described as a \u201cnightmare scenario for the public cloud.\u201d\n\n\u201cAzurescape is evidence that they\u2019re more real than we\u2019d like to think,\u201d according to Unit 42. \u201cCloud providers invest heavily in securing their platforms, but it\u2019s inevitable that unknown zero-day vulnerabilities would exist and put customers at risk.\u201d\n\n## **Best Practices for Container Defense**\n\nContainerized environments can present unique challenges for observability and in the application of security controls, Nunnikhoven noted, but following a layered security approach can help.\n\n\u201cGiven the speed of change and the scale of these environments, organizations must be able to quickly analyze the operational data looking for abnormal behaviors,\u201d he said. \u201cThe traditional approach of having a list of \u2018bad\u2019 things to look for won\u2019t work in a container-based environment.\u201d\n\nTo protect one\u2019s Kubernetes assets, users should implement a laundry list of best practices, researchers advised:\n\n * Keep cluster infrastructure patched;\n * Avoid default configurations;\n * Employ strong passwords;\n * Refrain from sending privileged service accounts tokens to anyone but the API server to prevent attackers from masquerading as the token owner;\n * Enable the \u201cBoundServiceAccountTokenVolume\u201d feature: When a pod terminates, its token is no longer valid, minimizing the impact of token theft;\n * Deploy policy enforcers to monitor and prevent suspicious activity within clusters, especially service accounts or nodes that query the SelfSubjectAccessReview or SelfSubjectRulesReview APIs for their permissions;\n * Pull container images from reputable sources, stored in secured repositories, tagged and signed with trust certificates. When new versions become available, archive outdated versions from the repositories;\n * Evaluate orchestrators for least-privilege configurations to ensure that movements within CI/CD are authenticated, logged and monitored;\n * Be holistic: Create a consolidated view of risk across cloud-application environments as well as traditional IT infrastructure;\n * Have data-analysis tooling in place and an automated runbook that can react to the results of that analysis;\n * Provide the context and information to your security analysts to make a timely and informed decision, and then run the appropriate automated response; and\n * Protect data at ingress and egress.\n\n\u201cAs containers multiply, so does the attack surface open up, which gives more entryways into the company\u2019s operational environment,\u201d said comforte AG\u2019s Morgan. \u201cLearn from reported breaches and other incidents. They are not just situations that happen to other companies \u2013 your business right now may be sustaining an attack somewhere, perhaps on your container environment. Assume that that\u2019s the case and act accordingly to audit, assess and bolster your defensive posture. The fallout is much more expensive and certainly is damaging to your organization as a whole.\u201d\n\n**_Moving to the cloud? Discover emerging cloud-security threats along with solid advice for how to defend your assets with our_**[ **_FREE downloadable eBook_**](<https://bit.ly/3Jy6Bfs>)**_, \u201cCloud Security: The Forecast for 2022.\u201d_** **_We explore organizations\u2019 top risks and challenges, best practices for defense, and advice for security success in such a dynamic computing environment, including handy checklists._**\n", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "NONE", "privilegesRequired": "NONE", "baseScore": 6.5, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 3.6}, "published": "2022-05-02T12:15:36", "type": "threatpost", "title": "Deep Dive: Protecting Against Container Threats in the Cloud", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "NONE", "availabilityImpact": "COMPLETE", "integrityImpact": "NONE", "baseScore": 7.1, "vectorString": "AV:N/AC:M/Au:N/C:N/I:N/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157", "CVE-2021-20291"], "modified": "2022-05-02T12:15:36", "id": "THREATPOST:CCBBEA3067FE857C1A87F48128362DB2", "href": "https://threatpost.com/container_threats_cloud_defend/179452/", "cvss": {"score": 7.1, "vector": "AV:N/AC:M/Au:N/C:N/I:N/A:C"}}, {"lastseen": "2020-10-26T18:29:40", "description": "A security vulnerability can be exploited to coerce the containerd cloud platform into exposing the host\u2019s registry or users\u2019 cloud-account credentials.\n\nContainerd [bills itself](<https://containerd.io/>) as a runtime tool that \u201cmanages the complete container lifecycle of its host system, from image transfer and storage to container execution and supervision to low-level storage to network attachments and beyond.\u201d As such, it offers deep visibility into a user\u2019s cloud environment, across multiple vendors.\n\nThe bug (CVE-2020-15157) is located in the container image-pulling process, according to Gal Singer, researcher at Aqua. Adversaries can exploit this vulnerability by building dedicated container images designed to steal the host\u2019s token, then using the token to take over a cloud project, he explained.\n\n[](<https://threatpost.com/newsletter-sign/>)\n\n\u201cA container image is a combination of a manifest file and some individual layer files,\u201d he wrote in a [recent post](<https://blog.aquasec.com/cve-2020-15157-containerd-container-vulnerability>). \u201cThe manifest file [in Image V2 Schema 2 format]\u2026can contain a \u2018foreign layer\u2019 which is pulled from a remote registry. When using containerd, if the remote registry responds with an HTTP 401 status code, along with specific HTTP headers, the host will send an authentication token that can be stolen.\u201d\n\nHe added, \u201cthe manifest supports an optional field for an external URL from which content may be fetched, and it can be any registry or domain.\u201d\n\nThe attackers can thus exploit the problem by crafting a malicious image in a remote registry, and then convincing the user to access it through containerd (this can be done through email and other social-engineering avenues), according to the [National Vulnerability Database writeup](<https://nvd.nist.gov/vuln/detail/CVE-2020-15157>).\n\n\u201cIf an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control, and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image,\u201d according to the bug advisory. \u201cIn some cases, this may be the user\u2019s username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account.\u201d\n\n## **Non-Trivial Exploitation**\n\nResearcher Brad Geesaman at Darkbit, who did original research into the vulnerability (which he calls \u201cContainerDrip\u201d), put together a proof-of-concept (PoC) exploit for a related attack vector.\n\nOne of the hurdles for exploitation is the fact that containerd clients that pull images may be configured to authenticate to a remote registry in order to fetch private images, which would prevent it from accessing the malicious content. Instead, an attacker would need to place the tainted image into a remote registry that the user already authenticates to.\n\n\u201cThe question became: \u2018How do I get them to send their credentials to me [for remote-registry authentication]?'\u201d he said in [a posting](<https://darkbit.io/blog/cve-2020-15157-containerdrip>) earlier this month. \u201cAs it turns out, all you have to do is ask the right question.\u201d\n\nThe Google Kubernetes Engine (GKE) is a managed environment for running containerized applications, which can be integrated with containerd. When GKE clusters running COS_CONTAINERD and GKE 1.16 or below are given a deployment to run, a Basic Auth header shows up, which when base64 decoded, turns out to be the authentication token for the underlying Google Compute Engine, used to create virtual machines. This token is attached to the GKE cluster/nodepool.\n\n\u201cBy default in GKE, the [Google Cloud Platform] service account attached to the nodepool is the default compute service account and it is granted Project Editor,\u201d explained Geesaman.\n\nThat said, also by default, a function called GKE OAuth Scopes \u201cscopes down\u201d the available permissions of that token. Geesaman also found a workaround for that.\n\n\u201cIf the defaults were modified when creating the cluster to grant the [\u201cany\u201d] scope to the nodepool, this token would have no OAuth scope restrictions and would grant the full set of Project Editor IAM permissions in that GCP project,\u201d he explained.\n\nAnd from there, attackers can escalate privileges to \u201cProject Owner\u201d using a known attack vector [demonstrated at](<https://www.youtube.com/watch?v=Z-JFVJZ-HDA>) DEF CON 2020.\n\nHe added that the GKE path is one of many possible.\n\ncontainerd [patched](<https://github.com/containerd/containerd/releases/tag/v1.2.14>) the bug, which is listed as medium in severity, in version 1.2.4; containerd 1.3.x is not vulnerable.\n\nCloud security continues to be a challenge for organizations. Researchers earlier in October [disclosed two flaws](<https://threatpost.com/microsoft-azure-flaws-servers-takeover/159965/>) in Microsoft\u2019s Azure web hosting application service, App Services, which if exploited could enable an attacker to take over administrative servers. Over the summer, malware like the Doki backdoor was [found to be infesting](<https://threatpost.com/doki-backdoor-docker-servers-cloud/157871/>) Docker containers.\n\nIn April, a simple Docker container honeypot was [used in a lab test](<https://threatpost.com/poorly-secured-docker-image-rapid-attack/154874/>) to see just how quickly cybercriminals will move to compromise vulnerable cloud infrastructure. It was quickly attacked by four different criminal campaigns over the span of 24 hours.\n", "cvss3": {}, "published": "2020-10-26T17:12:13", "type": "threatpost", "title": "Containerd Bug Exposes Cloud Account Credentials", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-15157", "CVE-2020-5135"], "modified": "2020-10-26T17:12:13", "id": "THREATPOST:39625C47309704502299C3CF93814CFA", "href": "https://threatpost.com/containerd-bug-cloud-account-credentials/160546/", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-10-26T18:13:11", "description": "Nvidia, which makes gaming-friendly graphics processing units (GPUs), has issued fixes for two high-severity flaws in the Windows version of its GeForce Experience software.\n\nGeForce Experience is a supplemental application to the GeForce GTX graphics card \u2014 it keeps users\u2019 drivers up-to-date, automatically optimizes their game settings and more. GeForce Experience is installed by default on systems running NVIDIA GeForce products, Nvidia\u2019s brand of GPUs.\n\nThe most severe flaw of the two (CVE-2020-5977) can lead to a slew of malicious attacks on affected systems \u2013 including code execution, denial of service, escalation of privileges and information disclosure. It ranks 8.2 out of 10 on the CVSS scale, making it high severity.\n\n[](<https://threatpost.com/newsletter-sign/>)\n\nIn a Thursday security advisory, the graphics giant said users can \u201cdownload the updates from the [GeForce Experience Downloads](<https://www.geforce.com/geforce-experience/download>) page or open the client to automatically apply the security update.\u201d\n\nThe flaw specifically stems from the Nvidia Web Helper NodeJS Web Server. When users install GeForce Experience, Node.js runs on startup and provides a webserver connection with Nvidia. The issue here is that an uncontrolled search path is used to load a node module, [which occurs when](<https://cwe.mitre.org/data/definitions/427.html>) an application uses fixed search paths to find resources \u2013 but one or more locations of the path are under control of malicious user. Attackers can leverage tactics like DLL preloading, binary planting and insecure library loading in order to exploit this vulnerability.\n\nWhile further details regarding this specific flaw are not available from Nvidia, the company did say that attackers can leverage the flaw to execute code, launch a DoS attack, escalate their privileges or view sensitive data. Xavier DANEST with Decathlon was credited with discovering the flaw.\n\nNvidia on Thursday also issued patches for another high-severity flaw in the ShadowPlay component of GeForce Experience (CVE\u20112020\u20115990), which may lead to local privilege escalation, code execution, DoS or information disclosure. Hashim Jawad of ACTIVELabs was credited with discovering the flaw.\n\nVersions of Nvidia GeForce Experience for Windows prior to 3.20.5.70 are affected; users are urged to update to version 3.20.5.70.\n\nNvidia has previously warned of security issues affecting its GeForce brand, including an issue [affecting GeForce Experience in 2019](<https://threatpost.com/nvidia-geforce-experience-bug/143196/>) that could lead to code execution or denial of service of products if exploited.\n\nIn June, Nvidia fixed t[wo high-severity flaws that affected drivers](<https://threatpost.com/nvidia-windows-gamers-graphics-driver-bugs/156911/>) for Windows and Linux users, including ones that use Nvidia\u2019s GeForce, Quadro and Tesla software. And in March, [Nvidia issued patches for high-severity bugs](<https://threatpost.com/gamer-alert-serious-nvidia-flaw-plagues-graphics-driver/153380/>) in its graphics driver, which can be exploited by a local attacker to launch DoS or code-execution attacks, and also affected display drivers used in GeForce (as well as Quadro and Tesla-branded) GPUs for Windows.\n", "cvss3": {}, "published": "2020-10-23T14:09:28", "type": "threatpost", "title": "Nvidia Warns Gamers of Severe GeForce Experience Flaws", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2020-15157", "CVE-2020-5977", "CVE-2020-5990"], "modified": "2020-10-23T14:09:28", "id": "THREATPOST:939D3A37125502BC9EE7A2E56EB485A7", "href": "https://threatpost.com/nvidia-gamers-geforce-experience-flaws/160487/", "cvss": {"score": 0.0, "vector": "NONE"}}], "debian": [{"lastseen": "2021-10-21T17:58:05", "description": "- -------------------------------------------------------------------------\nDebian Security Advisory DSA-4865-1 security@debian.org\nhttps://www.debian.org/security/ Moritz Muehlenhoff\nFebruary 27, 2021 https://www.debian.org/security/faq\n- -------------------------------------------------------------------------\n\nPackage : docker.io\nCVE ID : CVE-2020-15157 CVE-2020-15257 CVE-2021-21284 CVE-2021-21285\n\nMultiple security issues were discovered in Docker, a Linux container\nruntime, which could result in denial of service, an information leak\nor privilege escalation.\n\nFor the stable distribution (buster), these problems have been fixed in\nversion 18.09.1+dfsg1-7.1+deb10u3.\n\nWe recommend that you upgrade your docker.io packages.\n\nFor the detailed security status of docker.io please refer to\nits security tracker page at:\nhttps://security-tracker.debian.org/tracker/docker.io\n\nFurther information about Debian Security Advisories, how to apply\nthese updates to your system and frequently asked questions can be\nfound at: https://www.debian.org/security/\n\nMailing list: debian-security-announce@lists.debian.org", "cvss3": {"exploitabilityScore": 2.3, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "attackComplexity": "LOW", "scope": "CHANGED", "attackVector": "ADJACENT_NETWORK", "availabilityImpact": "NONE", "integrityImpact": "HIGH", "baseScore": 6.8, "privilegesRequired": "LOW", "vectorString": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 4.0}, "published": "2021-02-27T18:36:39", "type": "debian", "title": "[SECURITY] [DSA 4865-1] docker.io security update", "bulletinFamily": "unix", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "NONE", "availabilityImpact": "PARTIAL", "integrityImpact": "NONE", "baseScore": 4.3, "vectorString": "AV:N/AC:M/Au:N/C:N/I:N/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 2.9, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-15157", "CVE-2020-15257", "CVE-2021-21284", "CVE-2021-21285"], "modified": "2021-02-27T18:36:39", "id": "DEBIAN:DSA-4865-1:E637E", "href": "https://lists.debian.org/debian-security-announce/2021/msg00046.html", "cvss": {"score": 4.3, "vector": "AV:N/AC:M/Au:N/C:N/I:N/A:P"}}], "redhat": [{"lastseen": "2021-10-19T20:38:41", "description": "Red Hat OpenShift Container Platform is Red Hat's cloud computing\nKubernetes application platform solution designed for on-premise or private\ncloud deployments.\n\nThis advisory contains the RPM packages for Red Hat OpenShift Container\nPlatform 4.7.0. See the following advisory for the container images for\nthis release:\n\nhttps://access.redhat.com/errata/RHSA-2020:5633\n\nAll OpenShift Container Platform 4.7 users are advised to upgrade to these\nupdated packages and images when they are available in the appropriate\nrelease channel. To check for available updates, use the OpenShift Console\nor the CLI oc command. Instructions for upgrading a cluster are available\nat\nhttps://docs.openshift.com/container-platform/4.7/updating/updating-cluster-between-minor.html#understanding-upgrade-channels_updating-cluster-between-minor.\n\nSecurity Fix(es):\n\n* gogo/protobuf: plugin/unmarshal/unmarshal.go lacks certain index validation (CVE-2021-3121)\n\n* kubernetes: Ceph RBD adminSecrets exposed in logs when loglevel >= 4 (CVE-2020-8566)\n\n* containerd: credentials leak during image pull (CVE-2020-15157)\n\n* python-rsa: bleichenbacher timing oracle attack against RSA decryption (CVE-2020-25658)\n\n* atomic-openshift: cross-namespace owner references can trigger deletions of valid children (CVE-2019-3884)\n\nFor more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "LOW", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "LOW", "baseScore": 8.6, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 4.7}, "published": "2021-02-24T13:56:32", "type": "redhat", "title": "(RHSA-2020:5634) Moderate: OpenShift Container Platform 4.7.0 packages security update", "bulletinFamily": "unix", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 7.5, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 6.4, "obtainUserPrivilege": false}, "cvelist": ["CVE-2019-3884", "CVE-2020-15157", "CVE-2020-25658", "CVE-2020-28362", "CVE-2020-8566", "CVE-2021-3121"], "modified": "2021-03-22T00:38:45", "id": "RHSA-2020:5634", "href": "https://access.redhat.com/errata/RHSA-2020:5634", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2021-10-19T20:38:28", "description": "Red Hat OpenShift Container Platform is Red Hat's cloud computing\nKubernetes application platform solution designed for on-premise or private\ncloud deployments.\n\nSecurity Fix(es):\n\n* jackson-databind: Serialization gadgets in com.pastdev.httpcomponents.configuration.JndiConfiguration (CVE-2020-24750)\n\n* gogo/protobuf: plugin/unmarshal/unmarshal.go lacks certain index validation (CVE-2021-3121)\n\n* golang.org/x/text: possibility to trigger an infinite loop in encoding/unicode could lead to crash (CVE-2020-14040)\n\nFor more details about the security issue(s), including the impact, a CVSS\nscore, acknowledgments, and other related information, refer to the CVE\npage(s) listed in the References section.\n\nThis advisory contains the RPM packages for Red Hat OpenShift Container\nPlatform 4.7.0. See the following advisory for the container images for\nthis release:\n\nhttps://access.redhat.com/errata/RHEA-2020:5633\n\nAll OpenShift Container Platform users are advised to upgrade to these\nupdated packages and images when they are available in the appropriate\nrelease channel. To check for available updates, use the OpenShift Console\nor the CLI oc command. Instructions for upgrading a cluster are available\nat\nhttps://docs.openshift.com/container-platform/4.7/updating/updating-cluster\n-between-minor.html#understanding-upgrade-channels_updating-cluster-between\n-minor.", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 9.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2021-02-24T14:47:52", "type": "redhat", "title": "(RHSA-2020:5635) Moderate: OpenShift Container Platform 4.7.0 extras and security update", "bulletinFamily": "unix", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2018-20843", "CVE-2019-13050", "CVE-2019-13225", "CVE-2019-13627", "CVE-2019-14889", "CVE-2019-15165", "CVE-2019-15903", "CVE-2019-16168", "CVE-2019-16935", "CVE-2019-17450", "CVE-2019-17546", "CVE-2019-19221", "CVE-2019-19906", "CVE-2019-19956", "CVE-2019-20218", "CVE-2019-20387", "CVE-2019-20388", "CVE-2019-20454", "CVE-2019-20807", "CVE-2019-20907", "CVE-2019-20916", "CVE-2019-3884", "CVE-2019-5018", "CVE-2019-8625", "CVE-2019-8710", "CVE-2019-8720", "CVE-2019-8743", "CVE-2019-8764", "CVE-2019-8766", "CVE-2019-8769", "CVE-2019-8771", "CVE-2019-8782", "CVE-2019-8783", "CVE-2019-8808", "CVE-2019-8811", "CVE-2019-8812", "CVE-2019-8813", "CVE-2019-8814", "CVE-2019-8815", "CVE-2019-8816", "CVE-2019-8819", "CVE-2019-8820", "CVE-2019-8823", "CVE-2019-8835", "CVE-2019-8844", "CVE-2019-8846", "CVE-2020-10018", "CVE-2020-10029", "CVE-2020-11793", "CVE-2020-13630", "CVE-2020-13631", "CVE-2020-13632", "CVE-2020-14040", "CVE-2020-14382", "CVE-2020-14391", "CVE-2020-14422", "CVE-2020-15157", "CVE-2020-15503", "CVE-2020-15999", "CVE-2020-1730", "CVE-2020-1751", "CVE-2020-1752", "CVE-2020-1971", "CVE-2020-24659", "CVE-2020-24750", "CVE-2020-25211", "CVE-2020-25658", "CVE-2020-29652", "CVE-2020-3862", "CVE-2020-3864", "CVE-2020-3865", "CVE-2020-3867", "CVE-2020-3868", "CVE-2020-3885", "CVE-2020-3894", "CVE-2020-3895", "CVE-2020-3897", "CVE-2020-3898", "CVE-2020-3899", "CVE-2020-3900", "CVE-2020-3901", "CVE-2020-3902", "CVE-2020-6405", "CVE-2020-7595", "CVE-2020-8492", "CVE-2020-8566", "CVE-2020-8619", "CVE-2020-8622", "CVE-2020-8623", "CVE-2020-8624", "CVE-2020-9327", "CVE-2020-9802", "CVE-2020-9803", "CVE-2020-9805", "CVE-2020-9806", "CVE-2020-9807", "CVE-2020-9843", "CVE-2020-9850", "CVE-2020-9862", "CVE-2020-9893", "CVE-2020-9894", "CVE-2020-9895", "CVE-2020-9915", "CVE-2020-9925", "CVE-2021-3121"], "modified": "2021-03-02T17:28:43", "id": "RHSA-2020:5635", "href": "https://access.redhat.com/errata/RHSA-2020:5635", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2021-10-19T20:38:19", "description": "Red Hat OpenShift Container Platform is Red Hat's cloud computing\nKubernetes application platform solution designed for on-premise or private\ncloud deployments.\n\nThis advisory contains the container images for Red Hat OpenShift Container\nPlatform 4.7.0. See the following advisory for the RPM packages for this\nrelease:\n\nhttps://access.redhat.com/errata/RHSA-2020:5634\n\nSpace precludes documenting all of the container images in this advisory. See the following Release Notes documentation, which will be updated shortly for this release, for details about these changes:\n\nhttps://docs.openshift.com/container-platform/4.7/release_notes/ocp-4-7-release-notes.html\n\nYou may download the oc tool and use it to inspect release image metadata as follows:\n\n(For x86_64 architecture)\n\n $ oc adm release info quay.io/openshift-release-dev/ocp-release:4.7.0-x86_64\n\nThe image digest is sha256:d74b1cfa81f8c9cc23336aee72d8ae9c9905e62c4874b071317a078c316f8a70\n\n(For s390x architecture)\n\n $ oc adm release info quay.io/openshift-release-dev/ocp-release:4.7.0-s390x\n\nThe image digest is sha256:a68ca03d87496ddfea0ac26b82af77231583a58a7836b95de85efe5e390ad45d\n\n(For ppc64le architecture)\n\n $ oc adm release info quay.io/openshift-release-dev/ocp-release:4.7.0-ppc64le\n\nThe image digest is sha256:bc7b04e038c8ff3a33b827f4ee19aa79b26e14c359a7dcc1ced9f3b58e5f1ac6\n\nAll OpenShift Container Platform 4.7 users are advised to upgrade to these updated packages and images when they are available in the appropriate release channel. To check for available updates, use the OpenShift Console or the CLI oc command. Instructions for upgrading a cluster are available at https://docs.openshift.com/container-platform/4.7/updating/updating-cluster-between-minor.html#understanding-upgrade-channels_updating-cluster-between-minor.\n\nSecurity Fix(es):\n\n* crewjam/saml: authentication bypass in saml authentication (CVE-2020-27846)\n\n* golang: crypto/ssh: crafted authentication request can lead to nil pointer dereference (CVE-2020-29652)\n\n* gogo/protobuf: plugin/unmarshal/unmarshal.go lacks certain index validation (CVE-2021-3121)\n\n* nodejs-y18n: prototype pollution vulnerability (CVE-2020-7774)\n\n* kubernetes: Secret leaks in kube-controller-manager when using vSphere Provider (CVE-2020-8563)\n\n* containernetworking/plugins: IPv6 router advertisements allow for MitM attacks on IPv4 clusters (CVE-2020-10749)\n\n* heketi: gluster-block volume password details available in logs (CVE-2020-10763)\n\n* golang.org/x/text: possibility to trigger an infinite loop in encoding/unicode could lead to crash (CVE-2020-14040)\n\n* jwt-go: access restriction bypass vulnerability (CVE-2020-26160)\n\n* golang-github-gorilla-websocket: integer overflow leads to denial of service (CVE-2020-27813)\n\n* golang: math/big: panic during recursive division of very large numbers (CVE-2020-28362)\n\nFor more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 9.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2021-02-24T14:49:26", "type": "redhat", "title": "(RHSA-2020:5633) Moderate: OpenShift Container Platform 4.7.0 security, bug fix, and enhancement update", "bulletinFamily": "unix", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 10.0, "vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2018-10103", "CVE-2018-10105", "CVE-2018-14461", "CVE-2018-14462", "CVE-2018-14463", "CVE-2018-14464", "CVE-2018-14465", "CVE-2018-14466", "CVE-2018-14467", "CVE-2018-14468", "CVE-2018-14469", "CVE-2018-14470", "CVE-2018-14553", "CVE-2018-14879", "CVE-2018-14880", "CVE-2018-14881", "CVE-2018-14882", "CVE-2018-16227", "CVE-2018-16228", "CVE-2018-16229", "CVE-2018-16230", "CVE-2018-16300", "CVE-2018-16451", "CVE-2018-16452", "CVE-2018-20843", "CVE-2019-11068", "CVE-2019-12614", "CVE-2019-13050", "CVE-2019-13225", "CVE-2019-13627", "CVE-2019-14889", "CVE-2019-15165", "CVE-2019-15166", "CVE-2019-15903", "CVE-2019-15917", "CVE-2019-15925", "CVE-2019-16167", "CVE-2019-16168", "CVE-2019-16231", "CVE-2019-16233", "CVE-2019-16935", "CVE-2019-17450", "CVE-2019-17546", "CVE-2019-18197", "CVE-2019-18808", "CVE-2019-18809", "CVE-2019-19046", "CVE-2019-19056", "CVE-2019-19062", "CVE-2019-19063", "CVE-2019-19068", "CVE-2019-19072", "CVE-2019-19221", "CVE-2019-19319", "CVE-2019-19332", "CVE-2019-19447", "CVE-2019-19524", "CVE-2019-19533", "CVE-2019-19537", "CVE-2019-19543", "CVE-2019-19602", "CVE-2019-19767", "CVE-2019-19770", "CVE-2019-19906", "CVE-2019-19956", "CVE-2019-20054", "CVE-2019-20218", "CVE-2019-20386", "CVE-2019-20387", "CVE-2019-20388", "CVE-2019-20454", "CVE-2019-20636", "CVE-2019-20807", "CVE-2019-20812", "CVE-2019-20907", "CVE-2019-20916", "CVE-2019-3884", "CVE-2019-5018", "CVE-2019-6977", "CVE-2019-6978", "CVE-2019-8625", "CVE-2019-8710", "CVE-2019-8720", "CVE-2019-8743", "CVE-2019-8764", "CVE-2019-8766", "CVE-2019-8769", "CVE-2019-8771", "CVE-2019-8782", "CVE-2019-8783", "CVE-2019-8808", "CVE-2019-8811", "CVE-2019-8812", "CVE-2019-8813", "CVE-2019-8814", "CVE-2019-8815", "CVE-2019-8816", "CVE-2019-8819", "CVE-2019-8820", "CVE-2019-8823", "CVE-2019-8835", "CVE-2019-8844", "CVE-2019-8846", "CVE-2019-9455", "CVE-2019-9458", "CVE-2020-0305", "CVE-2020-0444", "CVE-2020-10018", "CVE-2020-10029", "CVE-2020-10732", "CVE-2020-10749", "CVE-2020-10751", "CVE-2020-10763", "CVE-2020-10773", "CVE-2020-10774", "CVE-2020-10942", "CVE-2020-11565", "CVE-2020-11668", "CVE-2020-11793", "CVE-2020-12465", "CVE-2020-12655", "CVE-2020-12659", "CVE-2020-12770", "CVE-2020-12826", "CVE-2020-13249", "CVE-2020-13630", "CVE-2020-13631", "CVE-2020-13632", "CVE-2020-14019", "CVE-2020-14040", "CVE-2020-14381", "CVE-2020-14382", "CVE-2020-14391", "CVE-2020-14422", "CVE-2020-15157", "CVE-2020-15503", "CVE-2020-15862", "CVE-2020-15999", "CVE-2020-16166", "CVE-2020-1716", "CVE-2020-1730", "CVE-2020-1751", "CVE-2020-1752", "CVE-2020-1971", "CVE-2020-24490", "CVE-2020-24659", "CVE-2020-25211", "CVE-2020-25641", "CVE-2020-25658", "CVE-2020-25661", "CVE-2020-25662", "CVE-2020-25681", "CVE-2020-25682", "CVE-2020-25683", "CVE-2020-25684", "CVE-2020-25685", "CVE-2020-25686", "CVE-2020-25687", "CVE-2020-25694", "CVE-2020-25696", "CVE-2020-2574", "CVE-2020-26160", "CVE-2020-2752", "CVE-2020-27813", "CVE-2020-27846", "CVE-2020-28362", "CVE-2020-2922", "CVE-2020-29652", "CVE-2020-3862", "CVE-2020-3864", "CVE-2020-3865", "CVE-2020-3867", "CVE-2020-3868", "CVE-2020-3885", "CVE-2020-3894", "CVE-2020-3895", "CVE-2020-3897", "CVE-2020-3898", "CVE-2020-3899", "CVE-2020-3900", "CVE-2020-3901", "CVE-2020-3902", "CVE-2020-6405", "CVE-2020-7595", "CVE-2020-7774", "CVE-2020-8177", "CVE-2020-8492", "CVE-2020-8563", "CVE-2020-8566", "CVE-2020-8619", "CVE-2020-8622", "CVE-2020-8623", "CVE-2020-8624", "CVE-2020-8647", "CVE-2020-8648", "CVE-2020-8649", "CVE-2020-9327", "CVE-2020-9802", "CVE-2020-9803", "CVE-2020-9805", "CVE-2020-9806", "CVE-2020-9807", "CVE-2020-9843", "CVE-2020-9850", "CVE-2020-9862", "CVE-2020-9893", "CVE-2020-9894", "CVE-2020-9895", "CVE-2020-9915", "CVE-2020-9925", "CVE-2021-2007", "CVE-2021-26539", "CVE-2021-3121"], "modified": "2021-03-02T01:56:45", "id": "RHSA-2020:5633", "href": "https://access.redhat.com/errata/RHSA-2020:5633", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "suse": [{"lastseen": "2022-04-18T12:39:43", "description": "An update that solves 7 vulnerabilities, contains one\n feature and has one errata is now available.\n\nDescription:\n\n This update for conmon, libcontainers-common, libseccomp, podman fixes the\n following issues:\n\n podman was updated to 3.4.4.\n\n Security issues fixed:\n\n\n - fix CVE-2021-41190 [bsc#1193273], opencontainers: OCI manifest and index\n parsing confusion\n - fix CVE-2021-4024 [bsc#1193166], podman machine spawns gvproxy with\n port binded to all IPs\n - fix CVE-2021-20199 [bsc#1181640], Remote traffic to rootless containers\n is seen as orginating from localhost\n\n - Add: Provides: podman:/usr/bin/podman-remote subpackage for a clearer\n upgrade path from podman < 3.1.2\n\n Update to version 3.4.4:\n\n * Bugfixes\n\n - Fixed a bug where the podman exec command would, under some\n circumstances, print a warning message about failing to move conmon\n to the appropriate cgroup (#12535).\n - Fixed a bug where named volumes created as part of container\n creation (e.g. podman run --volume avolume:/a/mountpoint or similar)\n would be mounted with incorrect permissions (#12523).\n - Fixed a bug where the podman-remote create and podman-remote run\n commands did not properly handle the --entrypoint=\"\" option (to\n clear the container's entrypoint) (#12521).\n\n - Update to version 3.4.3:\n\n * Security\n\n - This release addresses CVE-2021-4024, where the podman machine\n command opened the gvproxy API (used to forward ports to podman\n machine VMs) to the public internet on port 7777.\n - This release addresses CVE-2021-41190, where incomplete\n specification of behavior regarding image manifests could lead to\n inconsistent decoding on different clients.\n\n * Features\n\n - The --secret type=mount option to podman create and podman run\n supports a new option, target=, which specifies where in the\n container the secret will be mounted (#12287).\n\n * Bugfixes\n\n - Fixed a bug where rootless Podman would occasionally print warning\n messages about failing to move the pause process to a new cgroup\n (#12065).\n - Fixed a bug where the podman run and podman create commands would,\n when pulling images, still require TLS even with registries set to\n Insecure via config file (#11933).\n - Fixed a bug where the podman generate systemd command generated\n units that depended on multi-user.target, which has been removed\n from some distributions (#12438).\n - Fixed a bug where Podman could not run containers with images that\n had /etc/ as a symlink (#12189).\n - Fixed a bug where the podman logs -f command would, when using the\n journald logs backend, exit immediately if the container had\n previously been restarted (#12263).\n - Fixed a bug where, in containers on VMs created by podman machine,\n the host.containers.internal name pointed to the VM, not the host\n system (#11642).\n - Fixed a bug where containers and pods created by the podman play\n kube command in VMs managed by podman machine would not\n automatically forward ports from the host machine (#12248).\n - Fixed a bug where podman machine init would fail on OS X when GNU\n Coreutils was installed (#12329).\n - Fixed a bug where podman machine start would exit before SSH on the\n started VM was accepting connections (#11532).\n - Fixed a bug where the podman run command with signal proxying\n (--sig-proxy) enabled could print an error if it attempted to send a\n signal to a container that had just exited (#8086).\n - Fixed a bug where the podman stats command would not return correct\n information for containers running Systemd as PID1 (#12400).\n - Fixed a bug where the podman image save command would fail on OS X\n when writing the image to STDOUT (#12402).\n - Fixed a bug where the podman ps command did not properly handle PS\n arguments which contained whitespace (#12452).\n - Fixed a bug where the podman-remote wait command could fail to\n detect that the container exited and return an error under some\n circumstances (#12457).\n - Fixed a bug where the Windows MSI installer for podman-remote would\n break the PATH environment variable by adding an extra \" (#11416).\n\n * API\n\n - The Libpod Play Kube endpoint now also accepts ConfigMap YAML as\n part of its payload, and will use provided any ConfigMap to\n configure provided pods and services.\n - Fixed a bug where the Compat Create endpoint for Containers would\n not always create the container's working directory if it did not\n exist (#11842).\n - Fixed a bug where the Compat Create endpoint for Containers returned\n an incorrect error message with 404 errors when the requested image\n was not found (#12315).\n - Fixed a bug where the Compat Create endpoint for Containers did not\n properly handle the HostConfig.Mounts field (#12419).\n - Fixed a bug where the Compat Archive endpoint for Containers did not\n properly report errors when the operation failed (#12420).\n - Fixed a bug where the Compat Build endpoint for Images ignored the\n layers query parameter (for caching intermediate layers from the\n build) (#12378).\n - Fixed a bug where the Compat Build endpoint for Images did not\n report errors in a manner compatible with Docker (#12392).\n - Fixed a bug where the Compat Build endpoint for Images would fail to\n build if the context directory was a symlink (#12409).\n - Fixed a bug where the Compat List endpoint for Images included\n manifest lists (and not just images) in returned results (#12453).\n\n - Update to version 3.4.2:\n\n * Fixed a bug where podman tag could not tag manifest lists (#12046).\n * Fixed a bug where built-in volumes specified by images would not be\n created correctly under some circumstances.\n * Fixed a bug where, when using Podman Machine on OS X, containers in\n pods did not have working port forwarding from the host (#12207).\n * Fixed a bug where the podman network reload command command on\n containers using the slirp4netns network mode and the rootlessport\n port forwarding driver would make an unnecessary attempt to restart\n rootlessport\n on containers that did not forward ports.\n * Fixed a bug where the podman generate kube command would generate YAML\n including some unnecessary (set to default) fields (e.g. empty SELinux\n and DNS configuration blocks, and the privileged flag when set to\n false) (#11995).\n * Fixed a bug where the podman pod rm command could, if interrupted at\n the right moment, leave a reference to an already-removed infra\n container behind (#12034).\n * Fixed a bug where the podman pod rm command would not remove pods with\n more than one container if all containers save for the infra container\n were stopped unless --force was specified (#11713).\n * Fixed a bug where the --memory flag to podman run and podman create\n did not accept a limit of 0 (which should specify unlimited memory)\n (#12002).\n * Fixed a bug where the remote Podman client's podman build command\n could attempt to build a Dockerfile in the working directory of the\n podman system service instance instead of the Dockerfile specified by\n the user (#12054).\n * Fixed a bug where the podman logs --tail command could function\n improperly (printing more output than requested) when the journald log\n driver was used.\n * Fixed a bug where containers run using the slirp4netns network mode\n with IPv6 enabled would not have IPv6 connectivity until several\n seconds after they started (#11062).\n * Fixed a bug where some Podman commands could cause an extra\n dbus-daemon process to be created (#9727).\n * Fixed a bug where rootless Podman would sometimes print warnings about\n a failure to move the pause process into a given CGroup (#12065).\n * Fixed a bug where the checkpointed field in podman inspect on a\n container was not set to false after a container was restored.\n * Fixed a bug where the podman system service command would print\n overly-verbose logs about request IDs (#12181).\n * Fixed a bug where Podman could, when creating a new container without\n a name explicitly specified by the user, sometimes use an\n auto-generated name already in use by another container if multiple\n containers were being created in parallel (#11735).\n\n Update to version 3.4.1:\n\n * Bugfixes\n\n - Fixed a bug where podman machine init could, under some\n circumstances, create invalid machine configurations which could not\n be started (#11824).\n - Fixed a bug where the podman machine list command would not properly\n populate some output fields.\n - Fixed a bug where podman machine rm could leave dangling sockets\n from the removed machine (#11393).\n - Fixed a bug where podman run --pids-limit=-1 was not supported (it\n now sets the PID limit in the container to unlimited) (#11782).\n - Fixed a bug where podman run and podman attach could throw errors\n about a closed network connection when STDIN was closed by the\n client (#11856).\n - Fixed a bug where the podman stop command could fail when run on a\n container that had another podman stop command run on it previously.\n - Fixed a bug where the --sync flag to podman ps was nonfunctional.\n - Fixed a bug where the Windows and OS X remote clients' podman stats\n command would fail (#11909).\n - Fixed a bug where the podman play kube command did not properly\n handle environment variables whose values contained an = (#11891).\n - Fixed a bug where the podman generate kube command could generate\n invalid annotations when run on containers with volumes that use\n SELinux relabelling (:z or :Z) (#11929).\n - Fixed a bug where the podman generate kube command would generate\n YAML including some unnecessary (set to default) fields (e.g. user\n and group, entrypoint, default protocol for forwarded ports)\n (#11914, #11915, and #11965).\n - Fixed a bug where the podman generate kube command could, under some\n circumstances, generate YAML including an invalid targetPort field\n for forwarded ports (#11930).\n - Fixed a bug where rootless Podman's podman info command could, under\n some circumstances, not read available CGroup controllers (#11931).\n - Fixed a bug where podman container checkpoint --export would fail to\n checkpoint any container created with --log-driver=none (#11974).\n\n * API\n\n - Fixed a bug where the Compat Create endpoint for Containers could\n panic when no options were passed to a bind mount of tmpfs (#11961).\n\n Update to version 3.4.0:\n\n * Features\n\n - Pods now support init containers! Init containers are containers\n which run before the rest of the pod starts. There are two types of\n init containers: \"always\", which always run before the pod is\n started, and \"once\", which only run the first time the pod starts\n and are subsequently removed. They can be added using the podman\n create command's --init-ctr option.\n - Support for init containers has also been added to podman play kube\n and podman generate kube - init containers contained in Kubernetes\n YAML will be created as Podman init containers, and YAML generated\n by Podman will include any init containers created.\n - The podman play kube command now supports building images. If the\n --build option is given and a directory with the name of the\n specified image exists in the current working directory and contains\n a valid Containerfile or Dockerfile, the image will be built and\n used for the container.\n - The podman play kube command now supports a new option, --teardown,\n which removes any pods and containers created by the given\n Kubernetes YAML.\n - The podman generate kube command now generates annotations for\n SELinux mount options on volume (:z and :Z) that are respected by\n the podman play kube command.\n - A new command has been added, podman pod logs, to return logs for\n all containers in a pod at the same time.\n - Two new commands have been added, podman volume export (to export a\n volume to a tar file) and podman volume import) (to populate a\n volume from a given tar file).\n - The podman auto-update command now supports simple rollbacks. If a\n container fails to start after an automatic update, it will be\n rolled back to the previous image and restarted again.\n - Pods now share their user namespace by default, and the podman pod\n create command now supports the --userns option. This allows\n rootless pods to be created with the --userns=keep-id option.\n - The podman pod ps command now supports a new filter with its\n --filter option, until, which returns pods created before a given\n timestamp.\n - The podman image scp command has been added. This command allows\n images to be transferred between different hosts.\n - The podman stats command supports a new option, --interval, to\n specify the amount of time before the information is refreshed.\n - The podman inspect command now includes ports exposed (but not\n published) by containers (e.g. ports from --expose when\n --publish-all is not specified).\n - The podman inspect command now has a new boolean value,\n Checkpointed, which indicates that a container was stopped as a\n result of a podman container checkpoint operation.\n - Volumes created by podman volume create now support setting quotas\n when run atop XFS. The size and inode options allow the maximum size\n and maximum number of inodes consumed by a volume to be limited.\n - The podman info command now outputs information on what log drivers,\n network drivers, and volume plugins are available for use (#11265).\n - The podman info command now outputs the current log driver in use,\n and the variant and codename of the distribution in use.\n - The parameters of the VM created by podman machine init (amount of\n disk space, memory, CPUs) can now be set in containers.conf.\n - The podman machine ls command now shows additional information\n (CPUs, memory, disk size) about VMs managed by podman machine.\n - The podman ps command now includes healthcheck status in container\n state for containers that have healthchecks (#11527).\n\n * Changes\n\n - The podman build command has a new alias, podman buildx, to improve\n compatibility with Docker. We have already added support for many\n docker buildx flags to podman build and aim to continue to do so.\n - Cases where Podman is run without a user session or a writable\n temporary files directory will now produce better error messages.\n - The default log driver has been changed from file to journald. The\n file driver did not properly support log rotation, so this should\n lead to a better experience. If journald is not available on the\n system, Podman will automatically revert to the file.\n - Podman no longer depends on ip for removing networks (#11403).\n - The deprecated --macvlan flag to podman network create now warns\n when it is used. It will be removed entirely in the Podman 4.0\n release.\n - The podman machine start command now prints a message when the VM is\n successfully started.\n - The podman stats command can now be used on containers that are\n paused.\n - The podman unshare command will now return the exit code of the\n command that was run in the user namespace (assuming the command was\n successfully run).\n - Successful healthchecks will no longer add a healthy line to the\n system log to reduce log spam.\n - As a temporary workaround for a lack of shortname prompts in the\n Podman remote client, VMs created by podman machine now default to\n only using the docker.io registry.\n\n * Bugfixes\n\n - Fixed a bug where whitespace in the definition of sysctls\n (particularly default sysctls specified in containers.conf) would\n cause them to be parsed incorrectly.\n - Fixed a bug where the Windows remote client improperly validated\n volume paths (#10900).\n - Fixed a bug where the first line of logs from a container run with\n the journald log driver could be skipped.\n - Fixed a bug where images created by podman commit did not include\n ports exposed by the container.\n - Fixed a bug where the podman auto-update command would ignore the\n io.containers.autoupdate.authfile label when pulling images (#11171).\n - Fixed a bug where the --workdir option to podman create and podman\n run could not be set to a directory where a volume was mounted\n (#11352).\n - Fixed a bug where systemd socket-activation did not properly work\n with systemd-managed Podman containers (#10443).\n - Fixed a bug where environment variable secrets added to a container\n were not available to exec sessions launched in the container.\n - Fixed a bug where rootless containers could fail to start the\n rootlessport port-forwarding service when XDG_RUNTIME_DIR was set to\n a long path.\n - Fixed a bug where arguments to the --systemd option to podman create\n and podman run were case-sensitive (#11387).\n - Fixed a bug where the podman manifest rm command would also remove\n images referenced by the manifest, not just the manifest itself\n (#11344).\n - Fixed a bug where the Podman remote client on OS X would not\n function properly if the TMPDIR environment variable was not set\n (#11418).\n - Fixed a bug where the /etc/hosts file was not guaranteed to contain\n an entry for localhost (this is still not guaranteed if --net=host\n is used; such containers will exactly match the host's /etc/hosts)\n (#11411).\n - Fixed a bug where the podman machine start command could print\n warnings about unsupported CPU features (#11421).\n - Fixed a bug where the podman info command could segfault when\n accessing cgroup information.\n - Fixed a bug where the podman logs -f command could hang when a\n container exited (#11461).\n - Fixed a bug where the podman generate systemd command could not be\n used on containers that specified a restart policy (#11438).\n - Fixed a bug where the remote Podman client's podman build command\n would fail to build containers if the UID and GID on the client were\n higher than 65536 (#11474).\n - Fixed a bug where the remote Podman client's podman build command\n would fail to build containers if the context directory was a\n symlink (#11732).\n - Fixed a bug where the --network flag to podman play kube was not\n properly parsed when a non-bridge network configuration was\n specified.\n - Fixed a bug where the podman inspect command could error when the\n container being inspected was removed as it was being inspected\n (#11392).\n - Fixed a bug where the podman play kube command ignored the default\n pod infra image specified in containers.conf.\n - Fixed a bug where the --format option to podman inspect was\n nonfunctional under some circumstances (#8785).\n - Fixed a bug where the remote Podman client's podman run and podman\n exec commands could skip a byte of output every 8192 bytes (#11496).\n - Fixed a bug where the podman stats command would print nonsensical\n results if the container restarted while it was running (#11469).\n - Fixed a bug where the remote Podman client would error when STDOUT\n was redirected on a Windows client (#11444).\n - Fixed a bug where the podman run command could return 0 when the\n application in the container exited with 125 (#11540).\n - Fixed a bug where containers with --restart=always set using the\n rootlessport port-forwarding service could not be restarted\n automatically.\n - Fixed a bug where the --cgroups=split option to podman create and\n podman run was silently discarded if the container was part of a pod.\n - Fixed a bug where the podman container runlabel command could fail\n if the image name given included a tag.\n - Fixed a bug where Podman could add an extra 127.0.0.1 entry to\n /etc/hosts under some circumstances (#11596).\n - Fixed a bug where the remote Podman client's podman untag command\n did not properly handle tags including a digest (#11557).\n - Fixed a bug where the --format option to podman ps did not properly\n support the table argument for tabular output.\n - Fixed a bug where the --filter option to podman ps did not properly\n handle filtering by healthcheck status (#11687).\n - Fixed a bug where the podman run and podman start --attach commands\n could race when retrieving the exit code of a container that had\n already been removed resulting in an error (e.g. by an external\n podman rm -f) (#11633).\n - Fixed a bug where the podman generate kube command would add default\n environment variables to generated YAML.\n - Fixed a bug where the podman generate kube command would add the\n default CMD from the image to generated YAML (#11672).\n - Fixed a bug where the podman rm --storage command could fail to\n remove containers under some circumstances (#11207).\n - Fixed a bug where the podman machine ssh command could fail when run\n on Linux (#11731).\n - Fixed a bug where the podman stop command would error when used on a\n container that was already stopped (#11740).\n - Fixed a bug where renaming a container in a pod using the podman\n rename command, then removing the pod using podman pod rm, could\n cause Podman to believe the new name of the container was\n permanently in use, despite the container being removed (#11750).\n\n * API\n\n - The Libpod Pull endpoint for Images now has a new query parameter,\n quiet, which (when set to true) suppresses image pull progress\n reports (#10612).\n - The Compat Events endpoint now includes several deprecated fields\n from the Docker v1.21 API for improved compatibility with older\n clients.\n - The Compat List and Inspect endpoints for Images now prefix image\n IDs with sha256: for improved Docker compatibility (#11623).\n - The Compat Create endpoint for Containers now properly sets defaults\n for healthcheck-related fields (#11225).\n - The Compat Create endpoint for Containers now supports volume\n options provided by the Mounts field (#10831).\n - The Compat List endpoint for Secrets now supports a new query\n parameter, filter, which allows returned results to be filtered.\n - The Compat Auth endpoint now returns the correct response code (500\n instead of 400) when logging into a registry fails.\n - The Version endpoint now includes information about the OCI runtime\n and Conmon in use (#11227).\n - Fixed a bug where the X-Registry-Config header was not properly\n handled, leading to errors when pulling images (#11235).\n - Fixed a bug where invalid query parameters could cause a null\n pointer dereference when creating error messages.\n - Logging of API requests and responses at trace level has been\n greatly improved, including the addition of an X-Reference-Id header\n to correlate requests and responses (#10053).\n\n Update to version 3.3.1:\n\n * Bugfixes\n\n - Fixed a bug where unit files created by podman generate systemd\n could not cleanup shut down containers when stopped by systemctl\n stop (#11304).\n - Fixed a bug where podman machine commands would not properly locate\n the gvproxy binary in some circumstances.\n - Fixed a bug where containers created as part of a pod using the\n --pod-id-file option would not join the pod's network namespace\n (#11303).\n - Fixed a bug where Podman, when using the systemd cgroups driver,\n could sometimes leak dbus sessions.\n - Fixed a bug where the until filter to podman logs and podman events\n was improperly handled, requiring input to be negated (#11158).\n - Fixed a bug where rootless containers using CNI networking run on\n systems using systemd-resolved for DNS would fail to start if\n resolved symlinked /etc/resolv.conf to an absolute path (#11358).\n\n * API\n\n - A large number of potential file descriptor leaks from improperly\n closing client connections have been fixed.\n\n Update to version 3.3.0:\n\n * Fix network aliases with network id\n * machine: compute sha256 as we read the image file\n * machine: check for file exists instead of listing directory\n * pkg/bindings/images.nTar(): slashify hdr.Name values\n * Volumes: Only remove from DB if plugin removal succeeds\n * For compatibility, ignore Content-Type\n * [v3.3] Bump c/image 5.15.2, buildah v1.22.3\n * Implement SD-NOTIFY proxy in conmon\n * Fix rootless cni dns without systemd stub resolver\n * fix rootlessport flake\n * Skip stats test in CGv1 container environments\n * Fix AVC denials in tests of volume mounts\n * Restore buildah-bud test requiring new images\n * Revert \".cirrus.yml: use fresh images for all VMs\"\n * Fix device tests using ls test files\n * Enhance priv. dev. check\n * Workaround host availability of /dev/kvm\n * Skip cgroup-parent test due to frequent flakes\n * Cirrus: Fix not uploading logformatter html\n\n Switch to crun (bsc#1188914)\n\n Update to version 3.2.3:\n\n * Bump to v3.2.3\n * Update release notes for v3.2.3\n * vendor containers/common(a)v0.38.16\n * vendor containers/buildah(a)v1.21.3\n * Fix race conditions in rootless cni setup\n * CNI-in-slirp4netns: fix bind-mount for\n /run/systemd/resolve/stub-resolv.conf\n * Make rootless-cni setup more robust\n * Support uid,gid,mode options for secrets\n * vendor containers/common(a)v0.38.15\n * [CI:DOCS] podman search: clarify that results depend on implementation\n * vendor containers/common(a)v0.38.14\n * vendor containers/common(a)v0.38.13\n * [3.2] vendor containers/common(a)v0.38.12\n * Bump README to v3.2.2\n * Bump to v3.2.3-dev\n\n - Update to version 3.2.2:\n * Bump to v3.2.2\n * fix systemcontext to use correct TMPDIR\n * Scrub podman commands to use report package\n * Fix volumes with uid and gid options\n * Vendor in c/common v0.38.11\n * Initial release notes for v3.2.2\n * Fix restoring of privileged containers\n * Fix handling of podman-remote build --device\n * Add support for podman remote build -f - .\n * Fix panic condition in cgroups.getAvailableControllers\n * Fix permissions on initially created named volumes\n * Fix building static podman-remote\n * add correct slirp ip to /etc/hosts\n * disable tty-size exec checks in system tests\n * Fix resize race with podman exec -it\n * Fix documentation of the --format option of podman push\n * Fix systemd-resolved detection.\n * Health Check is not handled in the compat LibpodToContainerJSON\n * Do not use inotify for OCICNI\n * getContainerNetworkInfo: lock netNsCtr before sync\n * [NO TESTS NEEDED] Create /etc/mtab with the correct ownership\n * Create the /etc/mtab file if does not exists\n * [v3.2] cp: do not allow dir->file copying\n * create: support images with invalid platform\n * vendor containers/common(a)v0.38.10\n * logs: k8s-file: restore poll sleep\n * logs: k8s-file: fix spurious error logs\n * utils: move message from warning to debug\n * Bump to v3.2.2-dev\n\n - Update to version 3.2.1:\n * Bump to v3.2.1\n * Updated release notes for v3.2.1\n * Fix network connect race with docker-compose\n * Revert \"Ensure minimum API version is set correctly in tests\"\n * Fall back to string for dockerfile parameter\n * remote events: fix --stream=false\n * [CI:DOCS] fix incorrect network remove api doc\n * remote: always send resize before the container starts\n * remote events: support labels\n * remote pull: cancel pull when connection is closed\n * Fix network prune api docs\n * Improve systemd-resolved detection\n * logs: k8s-file: fix race\n * Fix image prune --filter cmd behavior\n * Several shell completion fixes\n * podman-remote build should handle -f option properly\n * System tests: deal with crun 0.20.1\n * Fix build tags for pkg/machine...\n * Fix pre-checkpointing\n * container: ignore named hierarchies\n * [v3.2] vendor containers/common(a)v0.38.9\n * rootless: fix fast join userns path\n * [v3.2] vendor containers/common(a)v0.38.7\n * [v3.2] vendor containers/common(a)v0.38.6\n * Correct qemu options for Intel macs\n * Ensure minimum API version is set correctly in tests\n * Bump to v3.2.1-dev\n\n - Update to version 3.2.0:\n * Bump to v3.2.0\n * Fix network create macvlan with subnet option\n * Final release notes updates for v3.2.0\n * add ipv6 nameservers only when the container has ipv6 enabled\n * Use request context instead of background\n * [v.3.2] events: support disjunctive filters\n * System tests: add :Z to volume mounts\n * generate systemd: make mounts portable\n * vendor containers/storage(a)v1.31.3\n * vendor containers/common(a)v0.38.5\n * Bump to v3.2.0-dev\n * Bump to v3.2.0-RC3\n * Update release notes for v3.2.0-RC3\n * Fix race on podman start --all\n * Fix race condition in running ls container in a pod\n * docs: --cert-dir: point to containers-certs.d(5)\n * Handle hard links in different directories\n * Improve OCI Runtime error\n * Handle hard links in remote builds\n * Podman info add support for status of cgroup controllers\n * Drop container does not exist on removal to debugf\n * Downgrade API service routing table logging\n * add libimage events\n * docs: generate systemd: XDG_RUNTIME_DIR\n * Fix problem copying files when container is in host pid namespace\n * Bump to v3.2.0-dev\n * Bump to v3.2.0-RC2\n * update c/common\n * Update Cirrus DEST_BRANCH to v3.2\n * Updated vendors of c/image, c/storage, Buildah\n * Initial release notes for v3.2.0-RC2\n * Add script for identifying commits in release branches\n * Add host.containers.internal entry into container's etc/hosts\n * image prune: remove unused images only with `--all`\n * podman network reload add rootless support\n * Use more recent `stale` release...\n * network tutorial: update with rootless cni changes\n * [CI:DOCS] Update first line in intro page\n * Use updated VM images + updated automation tooling\n * auto-update service: prune images\n * make vendor\n * fix system upgrade tests\n * Print \"extracting\" only on compressed file\n * podman image tree: restore previous behavior\n * fix network restart always test\n * fix incorrect log driver in podman container image\n * Add support for cli network prune --filter flag\n * Move filter parsing to common utils\n * Bump github.com/containers/storage from 1.30.2 to 1.30.3\n * Update nix pin with `make nixpkgs`\n * [CI:DOCS] hack/bats - new helper for running system tests\n * fix restart always with slirp4netns\n * Bump github.com/opencontainers/runc from 1.0.0-rc93 to 1.0.0-rc94\n * Bump github.com/coreos/go-systemd/v22 from 22.3.1 to 22.3.2\n * Add host.serviceIsRemote to podman info results\n * Add client disconnect to build handler loop\n * Remove obsolete skips\n * Fix podman-remote build --rm=false ...\n * fix: improved \"containers/{name}/wait\" endpoint\n * Bump github.com/containers/storage from 1.30.1 to 1.30.2\n * Add envars to the generated systemd unit\n * fix: use UTC Time Stamps in response JSON\n * fix container startup for empty pidfile\n * Kube like pods should share ipc,net,uts by default\n * fix: compat API \"images/get\" for multiple images\n * Revert escaped double dash man page flag syntax\n * Report Download complete in Compatibility mode\n * Add documentation on short-names\n * Bump github.com/docker/docker\n * Adds support to preserve auto update labels in generate and play kube\n * [CI:DOCS] Stop conversion of `--` into en dash\n * Revert Patch to relabel if selinux not enabled\n * fix per review request\n * Add support for environment variable secrets\n * fix pre review request\n * Fix infinite loop in isPathOnVolume\n * Add containers.conf information for changing defaults\n * CI: run rootless tests under ubuntu\n * Fix wrong macvlan PNG in networking doc.\n * Add restart-policy to container filters & --filter to podman start\n * Fixes docker-compose cannot set static ip when use ipam\n * channel: simplify implementation\n * build: improve regex for iidfile\n * Bump github.com/onsi/gomega from 1.11.0 to 1.12.0\n * cgroup: fix rootless --cgroup-parent with pods\n * fix: docker APIv2 `images/get`\n * codespell cleanup\n * Minor podmanimage docs updates.\n * Fix handling of runlabel IMAGE and NAME\n * Bump to v3.2.0-dev\n * Bump to v3.2.0-rc1\n * rootless: improve automatic range split\n * podman: set volatile storage flag for --rm containers\n * Bump github.com/onsi/ginkgo from 1.16.1 to 1.16.2\n * Bump github.com/containers/image/v5 from 5.11.1 to 5.12.0\n * migrate Podman to containers/common/libimage\n * Add filepath glob support to --security-opt unmask\n * Force log_driver to k8s-file for containers in containers\n * add --mac-address to podman play kube\n * compat api: Networks must be empty instead of null\n * System tests: honor $OCI_RUNTIME (for CI)\n * is this a bug?\n * system test image: add arm64v8 image\n * Fix troubleshooting documentation on handling sublemental groups.\n * Add --all to podman start\n * Fix variable reference typo. in multi-arch image action\n * cgroup: always honor --cgroup-parent with cgroupfs\n * Bump github.com/uber/jaeger-client-go\n * Don't require tests for github-actions & metadata\n * Detect if in podman machine virtual vm\n * Fix multi-arch image workflow typo\n * [CI:DOCS] Add titles to remote docs (windows)\n * Remove unused VolumeList* structs\n * Cirrus: Update F34beta -> F34\n * Update container image docs + fix unstable execution\n * Bump github.com/containers/storage from 1.30.0 to 1.30.1\n * TODO complete\n * Docker returns 'die' status rather then 'died' status\n * Check if another VM is running on machine start\n * [CI:DOCS] Improve titles of command HTML pages\n * system tests: networking: fix another race condition\n * Use seccomp_profile as default profile if defined in containers.conf\n * Bump github.com/json-iterator/go from 1.1.10 to 1.1.11\n * Vendored\n * Autoupdate local label functional\n * System tests: fix two race conditions\n * Add more documentation on conmon\n * Allow docker volume create API to pass without name\n * Cirrus: Update Ubuntu images to 21.04\n * Skip blkio-weight test when no kernel BFQ support\n * rootless: Tell the user what was led to the error, not just what it is\n * Add troubleshooting advice about the --userns option.\n * Fix images prune filter until\n * Fix logic for pushing stable multi-arch images\n * Fixes generate kube incorrect when bind-mounting \"/\" and \"/root\"\n * libpod/image: unit tests: don't use system's registries.conf.d\n * runtime: create userns when CAP_SYS_ADMIN is not present\n * rootless: attempt to copy current mappings first\n * [CI:DOCS] Restore missing content to manpages\n * [CI:DOCS] Fix Markdown layout bugs\n * Fix podman ps --filter ancestor to match exact ImageName/ImageID\n * Add machine-enabled to containers.conf for machine\n * Several multi-arch image build/push fixes\n * Add podman run --timeout option\n * Parse slirp4netns net options with compat api\n * Fix rootlesskit port forwarder with custom slirp cidr\n * Fix removal race condition in ListContainers\n * Add github-action workflow to build/push multi-arch\n * rootless: if root is not sub?id raise a debug message\n * Bump github.com/containers/common from 0.36.0 to 0.37.0\n * Add go template shell completion for --format\n * Add --group-add keep-groups: suplimentary groups into container\n * Fixes from make codespell\n * Typo fix to usage text of --compress option\n * corrupt-image test: fix an oops\n * Add --noheading flag to all list commands\n * Bump github.com/containers/storage from 1.29.0 to 1.30.0\n * Bump github.com/containers/image/v5 from 5.11.0 to 5.11.1\n * [CI:DOCS] Fix Markdown table layout bugs\n * podman-remote should show podman.sock info\n * rmi: don't break when the image is missing a manifest\n * [CI:DOCS] Rewrite --uidmap doc in podman-create.1.md and\n podman-run.1.md\n * Add support for CDI device configuration\n * [CI:DOCS] Add missing dash to verbose option\n * Bump github.com/uber/jaeger-client-go\n * Remove an advanced layer diff function\n * Ensure mount destination is clean, no trailing slash\n * add it for inspect pidfile\n * [CI:DOCS] Fix introduction page typo\n * support pidfile on container restore\n * fix start it\n * skip pidfile test on remote\n * improve document\n * set pidfile default value int containerconfig\n * add pidfile in inspection\n * add pidfile it for container start\n * skip pidfile it on remote\n * Modify according to comments\n * WIP: drop test requirement\n * runtime: bump required conmon version\n * runtime: return findConmon to libpod\n * oci: drop ExecContainerCleanup\n * oci: use `--full-path` option for conmon\n * use AttachSocketPath when removing conmon files\n * hide conmon-pidfile flag on remote mode\n * Fix possible panic in libpod/image/prune.go\n * add --ip to podman play kube\n * add flag autocomplete\n * add ut\n * add flag \"--pidfile\" for podman create/run\n * Add network bindings tests: remove and list\n * Fix build with GO111MODULE=off\n * system tests: build --pull-never: deal with flakes\n * compose test: diagnose flakes v3\n * podman play kube apply correct log driver\n * Fixes podman-remote save to directories does not work\n * Bump github.com/rootless-containers/rootlesskit from 0.14.1 to 0.14.2\n * Update documentation of podman-run to reflect volume \"U\" option\n * Fix flake on failed podman-remote build : try 2\n * compose test: ongoing efforts to diagnose flakes\n * Test that we don't error out on advertised --log-level values\n * At trace log level, print error text using %+v instead of %v\n * pkg/errorhandling.JoinErrors: don't throw away context for lone errors\n * Recognize --log-level=trace\n * Fix flake on failed podman-remote build\n * System tests: fix racy podman-inspect\n * Fixes invalid expression in save command\n * Bump github.com/containers/common from 0.35.4 to 0.36.0\n * Update nix pin with `make nixpkgs`\n * compose test: try to get useful data from flakes\n * Remove in-memory state implementation\n * Fix message about runtime to show only the actual runtime\n * System tests: setup: better cleanup of stray images\n * Bump github.com/containers/ocicrypt from 1.1.0 to 1.1.1\n * Reflect current state of prune implementation in docs\n * Do not delete container twice\n * [CI:DOCS] Correct status code for /pods/create\n * vendor in containers/storage v1.29.0\n * cgroup: do not set cgroup parent when rootless and cgroupfs\n * Overhaul Makefile binary and release worflows\n * Reorganize Makefile with sections and guide\n * Simplify Makefile help target\n * Don't shell to obtain current directory\n * Remove unnecessary/not-needed release.txt target\n * Fix incorrect version number output\n * Exclude .gitignore from test req.\n * Fix handling of $NAME and $IMAGE in runlabel\n * Update podman image Dockerfile to support Podman in container\n * Bump github.com/containers/image/v5 from 5.10.5 to 5.11.0\n * Fix slashes in socket URLs\n * Add network prune filters support to bindings\n * Add support for play/generate kube volumes\n * Update manifest API endpoints\n * Fix panic when not giving a machine name for ssh\n * cgroups: force 64 bits to ParseUint\n * Bump k8s.io/api from 0.20.5 to 0.21.0\n * [CI:DOCS] Fix formatting of podman-build man page\n * buildah-bud tests: simplify\n * Add missing return\n * Bump github.com/onsi/ginkgo from 1.16.0 to 1.16.1\n * speed up CI handling of images\n * Volumes prune endpoint should use only prune filters\n * Cirrus: Use Fedora 34beta images\n * Bump go.sum + Makefile for golang 1.16\n * Exempt Makefile changes from test requirements\n * Adjust libpod API Container Wait documentation to the code\n * [CI:DOCS] Update swagger definition of inspect manifest\n * use updated ubuntu images\n * podman unshare: add --rootless-cni to join the ns\n * Update swagger-check\n * swagger: remove name wildcards\n * Update buildah-bud diffs\n * Handle podman-remote --arch, --platform, --os\n * buildah-bud tests: handle go pseudoversions, plus...\n * Fix flaking rootless compose test\n * rootless cni add /usr/sbin to PATH if not present\n * System tests: special case for RHEL: require runc\n * Add --requires flag to podman run/create\n * [CI:DOCS] swagger-check: compare operations\n * [CI:DOCS] Polish swagger OpertionIDs\n * [NO TESTS NEEDED] Update nix pin with `make nixpkgs`\n * Ensure that `--userns=keep-id` sets user in config\n * [CI:DOCS] Set all operation id to be compatibile\n * Move operationIds to swagger:operation line\n * swagger: add operationIds that match with docker\n * Cirrus: Make use of shared get_ci_vm container\n * Don't relabel volumes if running in a privileged container\n * Allow users to override default storage opts with --storage-opt\n * Add support for podman --context default\n * Verify existence of auth file if specified\n * fix machine naming conventions\n * Initial network bindings tests\n * Update release notes to indicate CVE fix\n * Move socket activation check into init() and set global condition.\n * Bump github.com/onsi/ginkgo from 1.15.2 to 1.16.0\n * Http api tests for network prune with until filter\n * podman-run.1.md, podman-create.1.md : Adjust Markdown layout for\n --userns\n * Fix typos --uidmapping and --gidmapping\n * Add transport and destination info to manifest doc\n * Bump github.com/rootless-containers/rootlesskit from 0.14.0 to 0.14.1\n * Add default template functions\n * Fix missing podman-remote build options\n * Bump github.com/coreos/go-systemd/v22 from 22.3.0 to 22.3.1\n * Add ssh connection to root user\n * Add rootless docker-compose test to the CI\n * Use the slrip4netns dns in the rootless cni ns\n * Cleanup the rootless cni namespace\n * Add new docker-compose test for two networks\n * Make the docker-compose test work rootless\n * Remove unused rootless-cni-infra container files\n * Only use rootless RLK when the container has ports\n * Fix dnsname test\n * Enable rootless network connect/disconnect\n * Move slirp4netns functions into an extra file\n * Fix pod infra container cni network setup\n * Add rootless support for cni and --uidmap\n * rootless cni without infra container\n * Recreate until container prune tests for bindings\n * Remove --execute from podman machine ssh\n * Fixed podman-remote --network flag\n * Makefile: introduce install.docker-full\n * Makefile: ensure install.docker creates BINDIR\n * Fix unmount doc reference in image.rst\n * Should send the OCI runtime path not just the name to buildah\n * podman machine shell completion\n * Fix handling of remove --log-rusage param\n * Fix bindings prune containers flaky test\n * [CI:DOCS] Add local html build info to docs/README.md\n * Add podman machine list\n * Trim white space from /top endpoint results\n * Remove semantic version suffices from API calls\n * podman machine init --ignition-path\n * Document --volume from podman-remote run/create client\n * Update main branch to reflect the release of v3.1.0\n * Silence podman network reload errors with iptables-nft\n * Containers prune endpoint should use only prune filters\n * resolve proper aarch64 image names\n * APIv2 basic test: relax APIVersion check\n * Add machine support for qemu-system-aarch64\n * podman machine init user input\n * manpage xref: helpful diagnostic for unescaped dash-dash\n * Bump to v3.2.0-dev\n * swagger: update system version response body\n * buildah-bud tests: reenable pull-never test\n * [NO TESTS NEEDED] Shrink the size of podman-remote\n * Add powershell completions\n * [NO TESTS NEEDED] Drop Warning to Info, if cgroups not mounted\n * Fix long option format on docs.podman.io\n * system tests: friendier messages for 2-arg is()\n * service: use LISTEN_FDS\n * man pages: correct seccomp-policy label\n * rootless: use is_fd_inherited\n * podman generate systemd --new do not duplicate params\n * play kube: add support for env vars defined from secrets\n * play kube: support optional/mandatory env var from config map\n * play kube: prepare supporting other env source than config maps\n * Add machine support for more Linux distros\n * [NO TESTS NEEDED] Use same function podman-remote rmi as podman\n * Podman machine enhancements\n * Add problematic volume name to kube play error messages\n * Fix podman build --pull-never\n * [NO TESTS NEEDED] Fix for kernel without CONFIG_USER_NS\n * [NO TESTS NEEDED] Turn on podman-remote build --isolation\n * Fix list pods filter handling in libpod api\n * Remove resize race condition\n * [NO TESTS NEEDED] Vendor in containers/buildah v1.20.0\n * Use TMPDIR when commiting images\n * Add RequiresMountsFor= to systemd generate\n * Bump github.com/vbauerster/mpb/v6 from 6.0.2 to 6.0.3\n * Fix swapped dimensions from terminal.GetSize\n * Rename podman machine create to init and clean up\n * Correct json field name\n * system tests: new interactive tests\n * Improvements for machine\n * libpod/image: unit tests: use a `registries.conf` for aliases\n * libpod/image: unit tests: defer cleanup\n * libpod/image: unit tests: use `require.NoError`\n * Add --execute flag to podman machine ssh\n * introduce podman machine\n * Podman machine CLI and interface stub\n * Support multi doc yaml for generate/play kube\n * Fix filters in image http compat/libpod api endpoints\n * Bump github.com/containers/common from 0.35.3 to 0.35.4\n * Bump github.com/containers/storage from 1.28.0 to 1.28.1\n * Check if stdin is a term in --interactive --tty mode\n * [NO TESTS NEEDED] Remove /tmp/containers-users-* files on reboot\n * [NO TESTS NEEDED] Fix rootless volume plugins\n * Ensure manually-created volumes have correct ownership\n * Bump github.com/rootless-containers/rootlesskit\n * Unification of until filter across list/prune endpoints\n * Unification of label filter across list/prune endpoints\n * fixup\n * fix: build endpoint for compat API\n * [CI:DOCS] Add note to mappings for user/group userns in build\n * Bump k8s.io/api from 0.20.1 to 0.20.5\n * Validate passed in timezone from tz option\n * WIP: run buildah bud tests using podman\n * Fix containers list/prune http api filter behaviour\n * Generate Kubernetes PersistentVolumeClaims from named volumes\n\n - Update to version 3.1.2:\n * Bump to v3.1.2\n * Update release notes for v3.1.2\n * Ensure mount destination is clean, no trailing slash\n * Fixes podman-remote save to directories does not work\n * [CI:DOCS] Add missing dash to verbose option\n * [CI:DOCS] Fix Markdown table layout bugs\n * [CI:DOCS] Rewrite --uidmap doc in podman-create.1.md and\n podman-run.1.md\n * rmi: don't break when the image is missing a manifest\n * Bump containers/image to v5.11.1\n * Bump github.com/coreos/go-systemd from 22.2.0 to 22.3.1\n * Fix lint\n * Bump to v3.1.2-dev\n - Split podman-remote into a subpackage\n - Add missing scriptlets for systemd units\n - Escape macros in comments\n - Drop some obsolete workarounds, including %{go_nostrip}\n\n - Update to version 3.1.1:\n * Bump to v3.1.1\n * Update release notes for v3.1.1\n * podman play kube apply correct log driver\n * Fix build with GO111MODULE=off\n * [CI:DOCS] Set all operation id to be compatibile\n * Move operationIds to swagger:operation line\n * swagger: add operationIds that match with docker\n * Fix missing podman-remote build options\n * [NO TESTS NEEDED] Shrink the size of podman-remote\n * Move socket activation check into init() and set global condition.\n * rootless: use is_fd_inherited\n * Recreate until container prune tests for bindings\n * System tests: special case for RHEL: require runc\n * Document --volume from podman-remote run/create client\n * Containers prune endpoint should use only prune filters\n * Trim white space from /top endpoint results\n * Fix unmount doc reference in image.rst\n * Fix handling of remove --log-rusage param\n * Makefile: introduce install.docker-full\n * Makefile: ensure install.docker creates BINDIR\n * Should send the OCI runtime path not just the name to buildah\n * Fixed podman-remote --network flag\n * podman-run.1.md, podman-create.1.md : Adjust Markdown layout for\n --userns\n * Fix typos --uidmapping and --gidmapping\n * Add default template functions\n * Don't relabel volumes if running in a privileged container\n * Allow users to override default storage opts with --storage-opt\n * Add transport and destination info to manifest doc\n * Verify existence of auth file if specified\n * Ensure that `--userns=keep-id` sets user in config\n * [CI:DOCS] Update swagger definition of inspect manifest\n * Volumes prune endpoint should use only prune filters\n * Adjust libpod API Container Wait documentation to the code\n * Add missing return\n * [CI:DOCS] Fix formatting of podman-build man page\n * cgroups: force 64 bits to ParseUint\n * Fix slashes in socket URLs\n * [CI:DOCS] Correct status code for /pods/create\n * cgroup: do not set cgroup parent when rootless and cgroupfs\n * Reflect current state of prune implementation in docs\n * Do not delete container twice\n * Test that we don't error out on advertised --log-level values\n * At trace log level, print error text using %+v instead of %v\n * pkg/errorhandling.JoinErrors: don't throw away context for lone errors\n * Recognize --log-level=trace\n * Fix message about runtime to show only the actual runtime\n * Fix handling of $NAME and $IMAGE in runlabel\n * Fix flake on failed podman-remote build : try 2\n * Fix flake on failed podman-remote build\n * Update documentation of podman-run to reflect volume \"U\" option\n * Fixes invalid expression in save command\n * Fix possible panic in libpod/image/prune.go\n * Update all containers/ project vendors\n * Fix tests\n * Bump to v3.1.1-dev\n\n - Update to version 3.1.0:\n * Bump to v3.1.0\n * Fix test failure\n * Update release notes for v3.1.0 final release\n * [NO TESTS NEEDED] Turn on podman-remote build --isolation\n * Fix long option format on docs.podman.io\n * Fix containers list/prune http api filter behaviour\n * [CI:DOCS] Add note to mappings for user/group userns in build\n * Validate passed in timezone from tz option\n * Generate Kubernetes PersistentVolumeClaims from named volumes\n * libpod/image: unit tests: use a `registries.conf` for aliases\n - Require systemd 241 or newer due to podman dependency go-systemd v22,\n otherwise build will fail with unknown C name errors\n\n - Create docker subpackage to allow replacing docker with corresponding\n aliases to podman.\n\n - Update to v3.0.1\n * Changes\n - Several frequently-occurring WARN level log messages have been\n downgraded to INFO or DEBUG to not clutter terminal output. Bugfixes\n - Fixed a bug where the Created field of podman ps --format=json was\n formatted as a string instead of an Unix timestamp (integer) (#9315).\n - Fixed a bug where failing lookups of individual layers during the\n podman images command would cause the whole command to fail without\n printing output.\n - Fixed a bug where --cgroups=split did not function properly on\n cgroups v1 systems.\n - Fixed a bug where mounting a volume over an directory in the\n container that existed, but was empty, could fail (#9393).\n - Fixed a bug where mounting a volume over a directory in the\n container that existed could copy the entirety of the container's\n rootfs, instead of just the directory mounted over, into the volume\n (#9415).\n - Fixed a bug where Podman would treat the --entrypoint=[\"\"] option to\n podman run and podman create as a literal empty string in the\n entrypoint, when instead it should have been ignored (#9377).\n - Fixed a bug where Podman would set the HOME environment variable to\n \"\" when the container ran as a user without an assigned home\n directory (#9378).\n - Fixed a bug where specifying a pod infra image that had no tags (by\n using its ID) would cause podman pod create to panic (#9374).\n - Fixed a bug where the --runtime option was not properly handled by\n the podman build command (#9365).\n - Fixed a bug where Podman would incorrectly print an error message\n related to the remote API when the remote API was not in use and\n starting Podman failed.\n - Fixed a bug where Podman would change ownership of a container's\n working directory, even if it already existed (#9387).\n - Fixed a bug where the podman generate systemd --new command would\n incorrectly escape %t when generating the path for the PID file\n (#9373).\n - Fixed a bug where Podman could, when run inside a Podman container\n with the host's containers/storage directory mounted into the\n container, erroneously detect a reboot and reset container state if\n the temporary directory was not also mounted in (#9191).\n - Fixed a bug where some options of the podman build command\n (including but not limited to --jobs) were nonfunctional (#9247).\n * API\n - Fixed a breaking change to the Libpod Wait API for Containers where\n the Conditions parameter changed type in Podman v3.0 (#9351).\n - Fixed a bug where the Compat Create endpoint for Containers did not\n properly handle forwarded ports that did not specify a host port.\n - Fixed a bug where the Libpod Wait endpoint for Containers could\n write duplicate headers after an error occurred.\n - Fixed a bug where the Compat Create endpoint for Images would not\n pull images that already had a matching tag present locally, even if\n a more recent version was available at the registry (#9232).\n - The Compat Create endpoint for Images has had its compatibility with\n Docker improved, allowing its use with the docker-java library.\n * Misc\n - Updated Buildah to v1.19.4\n - Updated the containers/storage library to v1.24.6\n - Changes from v3.0.0\n * Features\n - Podman now features initial support for Docker Compose.\n - Added the podman rename command, which allows containers to be\n renamed after they are created (#1925).\n - The Podman remote client now supports the podman copy command.\n - A new command, podman network reload, has been added. This command\n will re-configure the network of all running containers, and can be\n used to recreate firewall rules lost when the system firewall was\n reloaded (e.g. via firewall-cmd --reload).\n - Podman networks now have IDs. They can be seen in podman network ls\n and can be used when removing and inspecting networks. Existing\n networks receive IDs automatically.\n - Podman networks now also support labels. They can be added via the\n --label option to network create, and podman network ls can filter\n labels based on them.\n - The podman network create command now supports setting bridge MTU\n and VLAN through the --opt option (#8454).\n - The podman container checkpoint and podman container restore\n commands can now checkpoint and restore containers that include\n volumes.\n - The podman container checkpoint command now supports the\n --with-previous and --pre-checkpoint options, and the podman\n container restore command now support the --import-previous option.\n These add support for two-step checkpointing with lowered dump times.\n - The podman push command can now push manifest lists. Podman will\n first attempt to push as an image, then fall back to pushing as a\n manifest list if that fails.\n - The podman generate kube command can now be run on multiple\n containers at once, and will generate a single pod containing all of\n them.\n - The podman generate kube and podman play kube commands now support\n Kubernetes DNS configuration, and will preserve custom DNS\n configuration when exporting or importing YAML (#9132).\n - The podman generate kube command now properly supports generating\n YAML for containers and pods creating using host networking\n (--net=host) (#9077).\n - The podman kill command now supports a --cidfile option to kill\n containers given a file containing the container's ID (#8443).\n - The podman pod create command now supports the --net=none option\n (#9165).\n - The podman volume create command can now specify volume UID and GID\n as options with the UID and GID fields passed to the the --opt\n option.\n - Initial support has been added for Docker Volume Plugins. Podman can\n now define available plugins in containers.conf and use them to\n create volumes with podman volume create --driver.\n - The podman run and podman create commands now support a new option,\n --platform, to specify the platform of the image to be used when\n creating the container.\n - The --security-opt option to podman run and podman create now\n supports the systempaths=unconfined option to unrestrict access to\n all paths in the container, as well as mask and unmask options to\n allow more granular restriction of container paths.\n - The podman stats --format command now supports a new format\n specified, MemUsageBytes, which prints the raw bytes of memory\n consumed by a container without human-readable formatting #8945.\n - The podman ps command can now filter containers based on what pod\n they are joined to via the pod filter (#8512).\n - The podman pod ps command can now filter pods based on what networks\n they are joined to via the network filter. The podman pod ps command\n can now print information on what networks a pod is joined to via\n the .Networks specifier to the --format option.\n - The podman system prune command now supports filtering what\n containers, pods, images, and volumes will be pruned.\n - The podman volume prune commands now supports filtering what volumes\n will be pruned.\n - The podman system prune command now includes information on space\n reclaimed (#8658).\n - The podman info command will now properly print information about\n packages in use on Gentoo and Arch systems.\n - The containers.conf file now contains an option for disabling\n creation of a new kernel keyring on container creation (#8384).\n - The podman image sign command can now sign multi-arch images by\n producing a signature for each image in a given manifest list.\n - The podman image sign command, when run as rootless, now supports\n per-user registry configuration files in\n $HOME/.config/containers/registries.d.\n - Configuration options for slirp4netns can now be set system-wide via\n the NetworkCmdOptions configuration option in containers.conf.\n - The MTU of slirp4netns can now be configured via the mtu= network\n command option (e.g. podman run --net slirp4netns:mtu=9000).\n * Security\n - A fix for CVE-2021-20199 is included. Podman between v1.8.0 and\n v2.2.1 used 127.0.0.1 as the source address for all traffic\n forwarded into rootless containers by a forwarded port; this has\n been changed to address the issue.\n * Changes\n - Shortname aliasing support has now been turned on by default. All\n Podman commands that must pull an image will, if a TTY is available,\n prompt the user about what image to pull.\n - The podman load command no longer accepts a NAME[:TAG] argument. The\n presence of this argument broke CLI compatibility with Docker by\n making docker load commands unusable with Podman (#7387).\n - The Go bindings for the HTTP API have been rewritten with a focus on\n limiting dependency footprint and improving extensibility. Read more\n here.\n - The legacy Varlink API has been completely removed from Podman.\n - The default log level for Podman has been changed from Error to Warn.\n - The podman network create command can now create macvlan networks\n using the --driver macvlan option for Docker compatibility. The\n existing --macvlan flag has been deprecated and will be removed in\n Podman 4.0 some time next year.\n - The podman inspect command has had the LogPath and LogTag fields\n moved into the LogConfig structure (from the root of the Inspect\n structure). The maximum size of the log file is also included.\n - The podman generate systemd command no longer generates unit files\n using the deprecated KillMode=none option (#8615).\n - The podman stop command now releases the container lock while\n waiting for it to stop - as such, commands like podman ps will no\n longer block until podman stop completes (#8501).\n - Networks created with podman network create --internal no longer use\n the dnsname plugin. This configuration never functioned as expected.\n - Error messages for the remote Podman client have been improved when\n it cannot connect to a Podman service.\n - Error messages for podman run when an invalid SELinux is specified\n have been improved.\n - Rootless Podman features improved support for containers with a\n single user mapped into the rootless user namespace.\n - Pod infra containers now respect default sysctls specified in\n containers.conf allowing for advanced configuration of the\n namespaces they will share.\n - SSH public key handling for remote Podman has been improved.\n * Bugfixes\n - Fixed a bug where the podman history --no-trunc command would\n truncate the Created By field (#9120).\n - Fixed a bug where root containers that did not explicitly specify a\n CNI network to join did not generate an entry for the network in use\n in the Networks field of the output of podman inspect (#6618).\n - Fixed a bug where, under some circumstances, container working\n directories specified by the image (via the WORKDIR instruction) but\n not present in the image, would not be created (#9040).\n - Fixed a bug where the podman generate systemd command would generate\n invalid unit files if the container was creating using a command\n line that included doubled braces ({{ and }}), e.g.\n --log-opt-tag={{.Name}} (#9034).\n - Fixed a bug where the podman generate systemd --new command could\n generate unit files including invalid Podman commands if the\n container was created using merged short options (e.g. podman run\n -dt) (#8847).\n - Fixed a bug where the podman generate systemd --new command could\n generate unit files that did not handle Podman commands including\n some special characters (e.g. $) (#9176\n - Fixed a bug where rootless containers joining CNI networks could not\n set a static IP address (#7842).\n - Fixed a bug where rootless containers joining CNI networks could not\n set network aliases (#8567).\n - Fixed a bug where the remote client could, under some circumstances,\n not include the Containerfile when sending build context to the\n server (#8374).\n - Fixed a bug where rootless Podman did not mount /sys as a new sysfs\n in some circumstances where it was acceptable.\n - Fixed a bug where rootless containers that both joined a user\n namespace and a CNI networks would cause a segfault. These options\n are incompatible and now return an error.\n - Fixed a bug where the podman play kube command did not properly\n handle CMD and ARGS from images (#8803).\n - Fixed a bug where the podman play kube command did not properly\n handle environment variables from images (#8608).\n - Fixed a bug where the podman play kube command did not properly\n print errors that occurred when starting containers.\n - Fixed a bug where the podman play kube command errored when\n hostNetwork was used (#8790).\n - Fixed a bug where the podman play kube command would always pull\n images when the :latest tag was specified, even if the image was\n available locally (#7838).\n - Fixed a bug where the podman play kube command did not properly\n handle SELinux configuration, rending YAML with custom SELinux\n configuration unusable (#8710).\n - Fixed a bug where the podman generate kube command incorrectly\n populated the args and command fields of generated YAML (#9211).\n - Fixed a bug where containers in a pod would create a duplicate entry\n in the pod's shared /etc/hosts file every time the container\n restarted (#8921).\n - Fixed a bug where the podman search --list-tags command did not\n support the --format option (#8740).\n - Fixed a bug where the http_proxy option in containers.conf was not\n being respected, and instead was set unconditionally to true (#8843).\n - Fixed a bug where rootless Podman could, on systems with a recent\n Conmon and users with a long username, fail to attach to containers\n (#8798).\n - Fixed a bug where the podman images command would break and fail to\n display any images if an empty manifest list was present in storage\n (#8931).\n - Fixed a bug where locale environment variables were not properly\n passed on to Conmon.\n - Fixed a bug where Podman would not build on the MIPS architecture\n (#8782).\n - Fixed a bug where rootless Podman could fail to properly configure\n user namespaces for rootless containers when the user specified a\n --uidmap option that included a mapping beginning with UID 0.\n - Fixed a bug where the podman logs command using the k8s-file backend\n did not properly handle partial log lines with a length of 1 (#8879).\n - Fixed a bug where the podman logs command with the --follow option\n did not properly handle log rotation (#8733).\n - Fixed a bug where user-specified HOSTNAME environment variables were\n overwritten by Podman (#8886).\n - Fixed a bug where Podman would applied default sysctls from\n containers.conf in too many situations (e.g. applying network\n sysctls when the container shared its network with a pod).\n - Fixed a bug where Podman did not properly handle cases where a\n secondary image store was in use and an image was present in both\n the secondary and primary stores (#8176).\n - Fixed a bug where systemd-managed rootless Podman containers where\n the user in the container was not root could fail as the container's\n PID file was not accessible to systemd on the host (#8506).\n - Fixed a bug where the --privileged option to podman run and podman\n create would, under some circumstances, not disable Seccomp (#8849).\n - Fixed a bug where the podman exec command did not properly add\n capabilities when the container or exec session were run with\n --privileged.\n - Fixed a bug where rootless Podman would use the --enable-sandbox\n option to slirp4netns unconditionally, even when pivot_root was\n disabled, rendering slirp4netns unusable when pivot_root was\n disabled (#8846).\n - Fixed a bug where podman build --logfile did not actually write the\n build's log to the logfile.\n - Fixed a bug where the podman system service command did not close\n STDIN, and could display user-interactive prompts (#8700).\n - Fixed a bug where the podman system reset command could, under some\n circumstances, remove all the contents of the XDG_RUNTIME_DIR\n directory (#8680).\n - Fixed a bug where the podman network create command created CNI\n configurations that did not include a default gateway (#8748).\n - Fixed a bug where the podman.service systemd unit provided by\n default used the wrong service type, and would cause systemd to not\n correctly register the service as started (#8751).\n - Fixed a bug where, if the TMPDIR environment variable was set for\n the container engine in containers.conf, it was being ignored.\n - Fixed a bug where the podman events command did not properly handle\n future times given to the --until option (#8694).\n - Fixed a bug where the podman logs command wrote container STDERR\n logs to STDOUT instead of STDERR (#8683).\n - Fixed a bug where containers created from an image with multiple\n tags would report that they were created from the wrong tag (#8547).\n - Fixed a bug where container capabilities were not set properly when\n the --cap-add=all and --user options to podman create and podman run\n were combined.\n - Fixed a bug where the --layers option to podman build was\n nonfunctional (#8643).\n - Fixed a bug where the podman system prune command did not act\n recursively, and thus would leave images, containers, pods, and\n volumes present that would be removed by a subsequent call to podman\n system prune (#7990).\n - Fixed a bug where the --publish option to podman run and podman\n create did not properly handle ports specified as a range of ports\n with no host port specified (#8650).\n - Fixed a bug where --format did not support JSON output for\n individual fields (#8444).\n - Fixed a bug where the podman stats command would fail when run on\n root containers using the slirp4netns network mode (#7883).\n - Fixed a bug where the Podman remote client would ask for a password\n even if the server's SSH daemon did not support password\n authentication (#8498).\n - Fixed a bug where the podman stats command would fail if the system\n did not support one or more of the cgroup controllers Podman\n supports (#8588).\n - Fixed a bug where the --mount option to podman create and podman run\n did not ignore the consistency mount option.\n - Fixed a bug where failures during the resizing of a container's TTY\n would print the wrong error.\n - Fixed a bug where the podman network disconnect command could cause\n the podman inspect command to fail for a container until it was\n restarted (#9234).\n - Fixed a bug where containers created from a read-only rootfs (using\n the --rootfs option to podman create and podman run) would fail\n (#9230).\n - Fixed a bug where specifying Go templates to the --format option to\n multiple Podman commands did not support the join function (#8773).\n - Fixed a bug where the podman rmi command could, when run in parallel\n on multiple images, return layer not known errors (#6510).\n - Fixed a bug where the podman inspect command on containers displayed\n unlimited ulimits incorrectly (#9303).\n - Fixed a bug where Podman would fail to start when a volume was\n mounted over a directory in a container that contained symlinks that\n terminated outside the directory and its subdirectories (#6003). API\n - Libpod API version has been bumped to v3.0.0.\n - All Libpod Pod APIs have been modified to properly report errors\n with individual containers. Cases where the operation as a whole\n succeeded but individual containers failed now report an HTTP 409\n error (#8865).\n - The Compat API for Containers now supports the Rename and Copy APIs.\n - Fixed a bug where the Compat Prune APIs (for volumes, containers,\n and images) did not return the amount of space reclaimed in their\n responses.\n - Fixed a bug where the Compat and Libpod Exec APIs for Containers\n would drop errors that occurred prior to the exec session\n successfully starting (e.g. a \"no such file\" error if an invalid\n executable was passed) (#8281)\n - Fixed a bug where the Volumes field in the Compat Create API for\n Containers was being ignored (#8649).\n - Fixed a bug where the NetworkMode field in the Compat Create API for\n Containers was not handling some values, e.g. container:, correctly.\n - Fixed a bug where the Compat Create API for Containers did not set\n container name properly.\n - Fixed a bug where containers created using the Compat Create API\n unconditionally used Kubernetes file logging (the default specified\n in containers.conf is now used).\n - Fixed a bug where the Compat Inspect API for Containers could\n include container states not recognized by Docker.\n - Fixed a bug where Podman did not properly clean up after calls to\n the Events API when the journald backend was in use, resulting in a\n leak of file descriptors (#8864).\n - Fixed a bug where the Libpod Pull endpoint for Images could fail\n with an index out of range error under certain circumstances (#8870).\n - Fixed a bug where the Libpod Exists endpoint for Images could panic.\n - Fixed a bug where the Compat List API for Containers did not support\n all filters (#8860).\n - Fixed a bug where the Compat List API for Containers did not\n properly populate the Status field.\n - Fixed a bug where the Compat and Libpod Resize APIs for Containers\n ignored the height and width parameters (#7102).\n - Fixed a bug where the Compat Search API for Images returned an\n incorrectly-formatted JSON response (#8758).\n - Fixed a bug where the Compat Load API for Images did not properly\n clean up temporary files.\n - Fixed a bug where the Compat Create API for Networks could panic\n when an empty IPAM configuration was specified.\n - Fixed a bug where the Compat Inspect and List APIs for Networks did\n not include Scope.\n - Fixed a bug where the Compat Wait endpoint for Containers did not\n support the same wait conditions that Docker did.\n * Misc\n - Updated Buildah to v1.19.2\n - Updated the containers/storage library to v1.24.5\n - Updated the containers/image library to v5.10.2\n - Updated the containers/common library to v0.33.4\n\n - Update to v2.2.1\n * Changes\n - Due to a conflict with a previously-removed field, we were forced to\n modify the way image volumes (mounting images into containers using\n --mount type=image) were handled in the database. As a result,\n containers created in Podman 2.2.0 with image volume will not have them in\n v2.2.1, and these containers will need to be re-created.\n * Bugfixes\n - Fixed a bug where rootless Podman would, on systems without the\n XDG_RUNTIME_DIR environment variable defined, use an incorrect path\n for the PID file of the Podman pause process, causing Podman to fail\n to start (#8539).\n - Fixed a bug where containers created using Podman v1.7 and earlier\n were unusable in Podman due to JSON decode errors (#8613).\n - Fixed a bug where Podman could retrieve invalid cgroup paths, instead\n of erroring, for containers that were not running.\n - Fixed a bug where the podman system reset command would print a\n warning about a duplicate shutdown handler being registered.\n - Fixed a bug where rootless Podman would attempt to mount sysfs in\n circumstances where it was not allowed; some OCI runtimes (notably\n crun) would fall back to alternatives and not fail, but others\n (notably runc) would fail to run containers.\n - Fixed a bug where the podman run and podman create commands would\n fail to create containers from untagged images (#8558).\n - Fixed a bug where remote Podman would prompt for a password even\n when the server did not support password authentication (#8498).\n - Fixed a bug where the podman exec command did not move the Conmon\n process for the exec session into the correct cgroup.\n - Fixed a bug where shell completion for the ancestor option to podman\n ps --filter did not work correctly.\n - Fixed a bug where detached containers would not properly clean\n themselves up (or remove themselves if --rm was set) if the Podman\n command that created them was invoked with --log-level=debug.\n * API\n - Fixed a bug where the Compat Create endpoint for Containers did not\n properly handle the Binds and Mounts parameters in HostConfig.\n - Fixed a bug where the Compat Create endpoint for Containers ignored\n the Name query parameter.\n - Fixed a bug where the Compat Create endpoint for Containers did not\n properly handle the \"default\" value for NetworkMode (this value is\n used extensively by docker-compose) (#8544).\n - Fixed a bug where the Compat Build endpoint for Images would\n sometimes incorrectly use the target query parameter as the image's\n tag.\n * Misc\n - Podman v2.2.0 vendored a non-released, custom version of the\n github.com/spf13/cobra package; this has been reverted to the latest\n upstream release to aid in packaging.\n - Updated the containers/image library to v5.9.0\n\n - Update to v2.2.0\n * Features\n - Experimental support for shortname aliasing has been added. This is\n not enabled by default, but can be turned on by setting the\n environment variable CONTAINERS_SHORT_NAME_ALIASING to on.\n Documentation is available here and here.\n - Initial support has been added for the podman network connect and\n podman network disconnect commands, which allow existing containers to\n modify what networks they are connected to. At present, these commands\n can only be used on running containers that did not specify\n --network=none when they were created.\n - The podman run command now supports the --network-alias option to set\n network aliases (additional names the container can be accessed at\n from other containers via DNS if the dnsname CNI plugin is in use).\n Aliases can also be added and removed using the new podman network\n connect and podman network disconnect commands. Please note that this\n requires a new release (v1.1.0) of the dnsname plugin, and will only\n work on newly-created CNI networks.\n - The podman generate kube command now features support for exporting\n container's memory and CPU limits (#7855).\n - The podman play kube command now features support for setting CPU and\n Memory limits for containers (#7742).\n - The podman play kube command now supports persistent volumes claims\n using Podman named volumes.\n - The podman play kube command now supports Kubernetes configmaps via\n the --configmap option (#7567).\n - The podman play kube command now supports a --log-driver option to set\n the log driver for created containers.\n - The podman play kube command now supports a --start option, enabled by\n default, to start the pod after creating it. This allows for podman\n play kube to be more easily used in systemd unitfiles.\n - The podman network create command now supports the --ipv6 option to\n enable dual-stack IPv6 networking for created networks (#7302).\n - The podman inspect command can now inspect pods, networks, and\n volumes, in addition to containers and images (#6757).\n - The --mount option for podman run and podman create now supports a new\n type, image, to mount the contents of an image into the container at a\n given location.\n - The Bash and ZSH completions have been completely reworked and have\n received significant enhancements! Additionally, support for Fish\n completions and completions for the podman-remote executable have been\n added.\n - The --log-opt option for podman create and podman run now supports the\n max-size option to set the maximum size for a container's logs (#7434).\n - The --network option to the podman pod create command now allows pods\n to be configured to use slirp4netns networking, even when run as root\n (#6097).\n - The podman pod stop, podman pod pause, podman pod unpause, and podman\n pod kill commands now work on multiple containers in parallel and\n should be significantly faster.\n - The podman search command now supports a --list-tags option to list\n all available tags for a single image in a single repository.\n - The podman search command can now output JSON using the --format=json\n option.\n - The podman diff and podman mount commands now work with all containers\n in the storage library, including those not created by Podman. This\n allows them to be used with Buildah and CRI-O containers.\n - The podman container exists command now features a --external option\n to check if a container exists not just in Podman, but also in the\n storage library. This will allow Podman to identify Buildah and CRI-O\n containers.\n - The --tls-verify and --authfile options have been enabled for use with\n remote Podman.\n - The /etc/hosts file now includes the container's name and hostname\n (both pointing to localhost) when the container is run with --net=none\n (#8095).\n - The podman events command now supports filtering events based on the\n labels of the container they occurred on using the --filter\n label=key=value option.\n - The podman volume ls command now supports filtering volumes based on\n their labels using the --filter label=key=value option.\n - The --volume and --mount options to podman run and podman create now\n support two new mount propagation options, unbindable and runbindable.\n - The name and id filters for podman pod ps now match based on a regular\n expression, instead of requiring an exact match.\n - The podman pod ps command now supports a new filter status, that\n matches pods in a certain state.\n * Changes\n - The podman network rm --force command will now also remove pods that\n are using the network (#7791).\n - The podman volume rm, podman network rm, and podman pod rm commands\n now return exit code 1 if the object specified for removal does not\n exist, and exit code 2 if the object is in use and the --force option\n was not given.\n - If /dev/fuse is passed into Podman containers as a device, Podman will\n open it before starting the container to ensure that the kernel module\n is loaded on the host and the device is usable in the container.\n - Global Podman options that were not supported with remote operation\n have been removed from podman-remote (e.g. --cgroup-manager,\n --storage-driver).\n - Many errors have been changed to remove repetition and be more clear\n as to what has gone wrong.\n - The --storage option to podman rm is now enabled by default, with\n slightly changed semantics. If the given container does not exist in\n Podman but does exist in the storage library, it will be removed even\n without the --storage option. If the container exists in Podman it\n will be removed normally. The --storage option for podman rm is now\n deprecated and will be removed in a future release.\n - The --storage option to podman ps has been renamed to --external. An\n alias has been added so the old form of the option will continue to\n work.\n - Podman now delays the SIGTERM and SIGINT signals during container\n creation to ensure that Podman is not stopped midway through creating\n a container resulting in potential resource leakage (#7941).\n - The podman save command now strips signatures from images it is\n exporting, as the formats we export to do not support signatures\n (#7659).\n - A new Degraded state has been added to pods. Pods that have some, but\n not all, of their containers running are now considered to be Degraded\n instead of Running.\n - Podman will now print a warning when conflicting network options\n related to port forwarding (e.g. --publish and --net=host) are\n specified when creating a container.\n - The --restart on-failure and --rm options for containers no longer\n conflict. When both are specified, the container will be restarted if\n it exits with a non-zero error code, and removed if it exits cleanly\n (#7906).\n - Remote Podman will no longer use settings from the client's\n containers.conf; defaults will instead be provided by the server's\n containers.conf (#7657).\n - The podman network rm command now has a new alias, podman network\n remove (#8402).\n * Bugfixes\n - Fixed a bug where podman load on the remote client did not error when\n attempting to load a directory, which is not yet supported for remote\n use.\n - Fixed a bug where rootless Podman could hang when the newuidmap binary\n was not installed (#7776).\n - Fixed a bug where the --pull option to podman run, podman create, and\n podman build did not match Docker's behavior.\n - Fixed a bug where sysctl settings from the containers.conf\n configuration file were applied, even if the container did not join\n the namespace associated with a sysctl.\n - Fixed a bug where Podman would not return the text of errors encounted\n when trying to run a healthcheck for a container.\n - Fixed a bug where Podman was accidentally setting the containers\n environment variable in addition to the expected container environment\n variable.\n - Fixed a bug where rootless Podman using CNI networking did not\n properly clean up DNS entries for removed containers (#7789).\n - Fixed a bug where the podman untag --all command was not supported\n with remote Podman.\n - Fixed a bug where the podman system service command could time out\n even if active attach connections were present (#7826).\n - Fixed a bug where the podman system service command would sometimes\n never time out despite no active connections being present.\n - Fixed a bug where Podman's handling of capabilities, specifically\n inheritable, did not match Docker's.\n - Fixed a bug where podman run would fail if the image specified was a\n manifest list and had already been pulled (#7798).\n - Fixed a bug where Podman did not take search registries into account\n when looking up images locally (#6381).\n - Fixed a bug where the podman manifest inspect command would fail for\n images that had already been pulled (#7726).\n - Fixed a bug where rootless Podman would not add supplemental GIDs to\n containers when when a user, but not a group, was set via the --user\n option to podman create and podman run and sufficient GIDs were\n available to add the groups (#7782).\n - Fixed a bug where remote Podman commands did not properly handle cases\n where the user gave a name that could also be a short ID for a pod or\n container (#7837).\n - Fixed a bug where podman image prune could leave images ready to be\n pruned after podman image prune was run (#7872).\n - Fixed a bug where the podman logs command with the journald log driver\n would not read all available logs (#7476).\n - Fixed a bug where the --rm and --restart options to podman create and\n podman run did not conflict when a restart policy that is not\n on-failure was chosen (#7878).\n - Fixed a bug where the --format \"table {{ .Field }}\" option to numerous\n Podman commands ceased to function on Podman v2.0 and up.\n - Fixed a bug where pods did not properly share an SELinux label between\n their containers, resulting in containers being unable to see the\n processes of other containers when the pod shared a PID namespace\n (#7886).\n - Fixed a bug where the --namespace option to podman ps did not work\n with the remote client (#7903).\n - Fixed a bug where rootless Podman incorrectly calculated the number of\n UIDs available in the container if multiple different ranges of UIDs\n were specified.\n - Fixed a bug where the /etc/hosts file would not be correctly populated\n for containers in a user namespace (#7490).\n - Fixed a bug where the podman network create and podman network remove\n commands could race when run in parallel, with unpredictable results\n (#7807).\n - Fixed a bug where the -p option to podman run, podman create, and\n podman pod create would, when given only a single number (e.g. -p 80),\n assign the same port for both host and container, instead of\n generating a random host port (#7947).\n - Fixed a bug where Podman containers did not properly store the cgroup\n manager they were created with, causing them to stop functioning after\n the cgroup manager was changed in containers.conf or with the\n --cgroup-manager option (#7830).\n - Fixed a bug where the podman inspect command did not include\n information on the CNI networks a container was connected to if it was\n not running.\n - Fixed a bug where the podman attach command would not print a newline\n after detaching from the container (#7751).\n - Fixed a bug where the HOME environment variable was not set properly\n in containers when the --userns=keep-id option was set (#8004).\n - Fixed a bug where the podman container restore command could panic\n when the container in question was in a pod (#8026).\n - Fixed a bug where the output of the podman image trust show --raw\n command was not properly formatted.\n - Fixed a bug where the podman runlabel command could panic if a label\n to run was not given (#8038).\n - Fixed a bug where the podman run and podman start --attach commands\n would exit with an error when the user detached manually using the\n detach keys on remote Podman (#7979).\n - Fixed a bug where rootless CNI networking did not use the dnsname CNI\n plugin if it was not available on the host, despite it always being\n available in the container used for rootless networking (#8040).\n - Fixed a bug where Podman did not properly handle cases where an OCI\n runtime is specified by its full path, and could revert to using\n another OCI runtime with the same binary path that existed in the\n system $PATH on subsequent invocations.\n - Fixed a bug where the --net=host option to podman create and podman\n run would cause the /etc/hosts file to be incorrectly populated\n (#8054).\n - Fixed a bug where the podman inspect command did not include container\n network information when the container shared its network namespace\n (IE, joined a pod or another container's network namespace via\n --net=container:...) (#8073).\n - Fixed a bug where the podman ps command did not include information on\n all ports a container was publishing.\n - Fixed a bug where the podman build command incorrectly forwarded STDIN\n into build containers from RUN instructions.\n - Fixed a bug where the podman wait command's --interval option did not\n work when units were not specified for the duration (#8088).\n - Fixed a bug where the --detach-keys and --detach options could be\n passed to podman create despite having no effect (and not making sense\n in that context).\n - Fixed a bug where Podman could not start containers if running on a\n system without a /etc/resolv.conf file (which occurs on some WSL2\n images) (#8089).\n - Fixed a bug where the --extract option to podman cp was nonfunctional.\n - Fixed a bug where the --cidfile option to podman run would, when the\n container was not run with --detach, only create the file after the\n container exited (#8091).\n - Fixed a bug where the podman images and podman images -a commands\n could panic and not list any images when certain improperly-formatted\n images were present in storage (#8148).\n - Fixed a bug where the podman events command could, when the journald\n events backend was in use, become nonfunctional when a badly-formatted\n event or a log message that container certain string was present in\n the journal (#8125).\n - Fixed a bug where remote Podman would, when using SSH transport, not\n authenticate to the server using hostkeys when connecting on a port\n other than 22 (#8139).\n - Fixed a bug where the podman attach command would not exit when\n containers stopped (#8154).\n - Fixed a bug where Podman did not properly clean paths before verifying\n them, resulting in Podman refusing to start if the root or temporary\n directories were specified with extra trailing / characters (#8160).\n - Fixed a bug where remote Podman did not support hashed hostnames in\n the known_hosts file on the host for establishing connections (#8159).\n - Fixed a bug where the podman image exists command would return\n non-zero (false) when multiple potential matches for the given name\n existed.\n - Fixed a bug where the podman manifest inspect command on images that\n are not manifest lists would error instead of inspecting the image\n (#8023).\n - Fixed a bug where the podman system service command would fail if the\n directory the Unix socket was to be created inside did not exist\n (#8184).\n - Fixed a bug where pods that shared the IPC namespace (which is done by\n default) did not share a /dev/shm filesystem between all containers in\n the pod (#8181).\n - Fixed a bug where filters passed to podman volume list were not\n inclusive (#6765).\n - Fixed a bug where the podman volume create command would fail when the\n volume's data directory already existed (as might occur when a volume\n was not completely removed) (#8253).\n - Fixed a bug where the podman run and podman create commands would\n deadlock when trying to create a container that mounted the same named\n volume at multiple locations (e.g. podman run -v testvol:/test1 -v\n testvol:/test2) (#8221).\n - Fixed a bug where the parsing of the --net option to podman build was\n incorrect (#8322).\n - Fixed a bug where the podman build command would print the ID of the\n built image twice when using remote Podman (#8332).\n - Fixed a bug where the podman stats command did not show memory limits\n for containers (#8265).\n - Fixed a bug where the podman pod inspect command printed the static\n MAC address of the pod in a non-human-readable format (#8386).\n - Fixed a bug where the --tls-verify option of the podman play kube\n command had its logic inverted (false would enforce the use of TLS,\n true would disable it).\n - Fixed a bug where the podman network rm command would error when\n trying to remove macvlan networks and rootless CNI networks (#8491).\n - Fixed a bug where Podman was not setting sane defaults for missing\n XDG_ environment variables.\n - Fixed a bug where remote Podman would check if volume paths to be\n mounted in the container existed on the host, not the server (#8473).\n - Fixed a bug where the podman manifest create and podman manifest add\n commands on local images would drop any images in the manifest not\n pulled by the host.\n - Fixed a bug where networks made by podman network create did not\n include the tuning plugin, and as such did not support setting custom\n MAC addresses (#8385).\n - Fixed a bug where container healthchecks did not use $PATH when\n searching for the Podman executable to run the healthcheck.\n - Fixed a bug where the --ip-range option to podman network create did\n not properly handle non-classful subnets when calculating the last\n usable IP for DHCP assignment (#8448).\n - Fixed a bug where the podman container ps alias for podman ps was\n missing (#8445).\n * API\n - The Compat Create endpoint for Container has received a major refactor\n to share more code with the Libpod Create endpoint, and should be\n significantly more stable.\n - A Compat endpoint for exporting multiple images at once, GET\n /images/get, has been added (#7950).\n - The Compat Network Connect and Network Disconnect endpoints have been\n added.\n - Endpoints that deal with image registries now support a\n X-Registry-Config header to specify registry authentication\n configuration.\n - The Compat Create endpoint for images now properly supports specifying\n images by digest.\n - The Libpod Build endpoint for images now supports an httpproxy query\n parameter which, if set to true, will forward the server's HTTP proxy\n settings into the build container for RUN instructions.\n - The Libpod Untag endpoint for images will now remove all tags for the\n given image if no repository and tag are specified for removal.\n - Fixed a bug where the Ping endpoint misspelled a header name\n (Libpod-Buildha-Version instead of Libpod-Buildah-Version).\n - Fixed a bug where the Ping endpoint sent an extra newline at the end\n of its response where Docker did not.\n - Fixed a bug where the Compat Logs endpoint for containers did not send\n a newline character after each log line.\n - Fixed a bug where the Compat Logs endpoint for containers would mangle\n line endings to change newline characters to add a preceding carriage\n return (#7942).\n - Fixed a bug where the Compat Inspect endpoint for Containers did not\n properly list the container's stop signal (#7917).\n - Fixed a bug where the Compat Inspect endpoint for Containers formatted\n the container's create time incorrectly (#7860).\n - Fixed a bug where the Compat Inspect endpoint for Containers did not\n include the container's Path, Args, and Restart Count.\n - Fixed a bug where the Compat Inspect endpoint for Containers prefixed\n added and dropped capabilities with CAP_ (Docker does not do so).\n - Fixed a bug where the Compat Info endpoint for the Engine did not\n include configured registries.\n - Fixed a bug where the server could panic if a client closed a\n connection midway through an image pull (#7896).\n - Fixed a bug where the Compat Create endpoint for volumes returned an\n error when a volume with the same name already existed, instead of\n succeeding with a 201 code (#7740).\n - Fixed a bug where a client disconnecting from the Libpod or Compat\n events endpoints could result in the server using 100% CPU (#7946).\n - Fixed a bug where the \"no such image\" error message sent by the Compat\n Inspect endpoint for Images returned a 404 status code with an error\n that was improperly formatted for Docker compatibility.\n - Fixed a bug where the Compat Create endpoint for networks did not\n properly set a default for the driver parameter if it was not provided\n by the client.\n - Fixed a bug where the Compat Inspect endpoint for images did not\n populate the RootFS field of the response.\n - Fixed a bug where the Compat Inspect endpoint for images would omit\n the ParentId field if the image had no parent, and the Created field\n if the image did not have a creation time.\n - Fixed a bug where the Compat Remove endpoint for Networks did not\n support the Force query parameter.\n\n - add dependency to timezone package or podman fails to build a\n - Correct invalid use of %{_libexecdir} to ensure files should be in\n /usr/lib SELinux support [jsc#SMO-15]\n\n\n libseccomp was updated to release 2.5.3:\n\n * Update the syscall table for Linux v5.15\n * Fix issues with multiplexed syscalls on mipsel introduced in v2.5.2\n * Document that seccomp_rule_add() may return -EACCES\n\n Update to release 2.5.2\n\n * Update the syscall table for Linux v5.14-rc7\n * Add a function, get_notify_fd(), to the Python bindings to get the\n nofication file descriptor.\n * Consolidate multiplexed syscall handling for all architectures into one\n location.\n * Add multiplexed syscall support to PPC and MIPS\n * The meaning of SECCOMP_IOCTL_NOTIF_ID_VALID changed within the kernel.\n libseccomp's fd notification logic was modified to support the kernel's\n previous and new usage of SECCOMP_IOCTL_NOTIF_ID_VALID.\n\n update to 2.5.1:\n\n * Fix a bug where seccomp_load() could only be called once\n * Change the notification fd handling to only request a notification fd if\n * the filter has a _NOTIFY action\n * Add documentation about SCMP_ACT_NOTIFY to the seccomp_add_rule(3)\n manpage\n * Clarify the maintainers' GPG keys\n\n Update to release 2.5.0\n\n * Add support for the seccomp user notifications, see the\n seccomp_notify_alloc(3), seccomp_notify_receive(3),\n seccomp_notify_respond(3) manpages for more information\n * Add support for new filter optimization approaches, including a balanced\n tree optimization, see the SCMP_FLTATR_CTL_OPTIMIZE filter attribute for\n more information\n * Add support for the 64-bit RISC-V architecture\n * Performance improvements when adding new rules to a filter thanks to the\n use of internal shadow transactions and improved syscall lookup tables\n * Properly document the libseccomp API return values and include them in\n the stable API promise\n * Improvements to the s390 and s390x multiplexed syscall handling\n * Multiple fixes and improvements to the libseccomp manpages\n * Moved from manually maintained syscall tables to an automatically\n generated syscall table in CSV format\n * Update the syscall tables to Linux v5.8.0-rc5\n * Python bindings and build now default to Python 3.x\n * Improvements to the tests have boosted code coverage to over 93%\n\n Update to release 2.4.3\n\n * Add list of authorized release signatures to README.md\n * Fix multiplexing issue with s390/s390x shm* syscalls\n * Remove the static flag from libseccomp tools compilation\n * Add define for __SNR_ppoll\n * Fix potential memory leak identified by clang in the scmp_bpf_sim tool\n\n Update to release 2.4.2\n\n * Add support for io-uring related system calls\n\n\n conmon was updated to version 2.0.30:\n\n * Remove unreachable code path\n * exit: report if the exit command was killed\n * exit: fix race zombie reaper\n * conn_sock: allow watchdog messages through the notify socket proxy\n * seccomp: add support for seccomp notify\n\n Update to version 2.0.29:\n\n * Reset OOM score back to 0 for container runtime\n * call functions registered with atexit on SIGTERM\n * conn_sock: fix potential segfault\n\n Update to version 2.0.27:\n\n * Add CRI-O integration test GitHub action\n * exec: don't fail on EBADFD\n * close_fds: fix close of external fds\n * Add arm64 static build binary\n\n Update to version 2.0.26:\n\n * conn_sock: do not fail on EAGAIN\n * fix segfault from a double freed pointer\n * Fix a bug where conmon could never spawn a container, because a\n disagreement between the caller and itself on where the attach socket\n was.\n * improve --full-attach to ignore the socket-dir directly. that means\n callers don't need to specify a socket dir at all (and can remove it)\n * add full-attach option to allow callers to not truncate a very long\n path for the attach socket\n * close only opened FDs\n * set locale to inherit environment\n\n Update to version 2.0.22:\n\n * added man page\n * attach: always chdir\n * conn_sock: Explicitly free a heap-allocated string\n * refactor I/O and add SD_NOTIFY proxy support\n\n Update to version 2.0.21:\n\n * protect against kill(-1)\n * Makefile: enable debuginfo generation\n * Remove go.sum file and add go.mod\n * Fail if conmon config could not be written\n * nix: remove double definition for e2fsprogs\n * Speedup static build by utilizing CI cache on `/nix` folder\n * Fix nix build for failing e2fsprogs tests\n * test: fix CI\n * Use Podman for building\n\n libcontainers-common was updated to include:\n\n - common 0.44.0\n - image 5.16.0\n - podman 3.3.1\n - storage 1.36.0 (changes too long to list)\n\n CVEs fixed:\n CVE-2020-14370,CVE-2020-15157,CVE-2021-20199,CVE-2021-20291,CVE-2021-3602\n\n\nPatch Instructions:\n\n To install this openSUSE Security Update use the SUSE recommended installation methods\n like YaST online_update or \"zypper patch\".\n\n Alternatively you can run the command listed for your product:\n\n - openSUSE Leap 15.3:\n\n zypper in -t patch openSUSE-SLE-15.3-2022-23018=1", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "LOW", "baseScore": 6.5, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 3.6}, "published": "2022-03-04T00:00:00", "type": "suse", "title": "Security update for conmon, libcontainers-common, libseccomp, podman (moderate)", "bulletinFamily": "unix", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "NONE", "availabilityImpact": "COMPLETE", "integrityImpact": "NONE", "baseScore": 7.1, "vectorString": "AV:N/AC:M/Au:N/C:N/I:N/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.9, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-14370", "CVE-2020-15157", "CVE-2021-20199", "CVE-2021-20291", "CVE-2021-3602", "CVE-2021-4024", "CVE-2021-41190"], "modified": "2022-03-04T00:00:00", "id": "OPENSUSE-SU-2022:23018-1", "href": "https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/5BA2TLW7O5ZURGQUAQUH4HD5SQYNDDZ6/", "cvss": {"score": 7.1, "vector": "AV:N/AC:M/Au:N/C:N/I:N/A:C"}}]}
Docker vulnerability
