All the vulnerabilites related to GNU - C Library
var-202101-0119
Vulnerability from variot
The iconv feature in the GNU C Library (aka glibc or libc6) through 2.32, when processing invalid multi-byte input sequences in the EUC-KR encoding, may have a buffer over-read. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
====================================================================
Red Hat Security Advisory
Synopsis: Moderate: glibc security, bug fix, and enhancement update Advisory ID: RHSA-2021:1585-01 Product: Red Hat Enterprise Linux Advisory URL: https://access.redhat.com/errata/RHSA-2021:1585 Issue date: 2021-05-18 CVE Names: CVE-2016-10228 CVE-2019-9169 CVE-2019-25013 CVE-2020-27618 CVE-2021-3326 ==================================================================== 1. Summary:
An update for glibc is now available for Red Hat Enterprise Linux 8.
Red Hat Product Security has rated this update as having a security impact of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.
- Relevant releases/architectures:
Red Hat CodeReady Linux Builder (v. 8) - aarch64, ppc64le, s390x, x86_64 Red Hat Enterprise Linux AppStream (v. 8) - aarch64, ppc64le, s390x, x86_64 Red Hat Enterprise Linux BaseOS (v. 8) - aarch64, ppc64le, s390x, x86_64
- Description:
The glibc packages provide the standard C libraries (libc), POSIX thread libraries (libpthread), standard math libraries (libm), and the name service cache daemon (nscd) used by multiple programs on the system. Without these libraries, the Linux system cannot function correctly.
Additional Changes:
For detailed information on changes in this release, see the Red Hat Enterprise Linux 8.4 Release Notes linked from the References section.
- Solution:
For details on how to apply this update, which includes the changes described in this advisory, refer to:
https://access.redhat.com/articles/11258
For the update to take effect, all services linked to the glibc library must be restarted, or the system rebooted.
- Bugs fixed (https://bugzilla.redhat.com/):
1428290 - CVE-2016-10228 glibc: iconv program can hang when invoked with the -c option 1684057 - CVE-2019-9169 glibc: regular-expression match via proceed_next_node in posix/regexec.c leads to heap-based buffer over-read 1704868 - CVE-2016-10228 glibc: iconv: Fix converter hangs and front end option parsing for //TRANSLIT and //IGNORE [rhel-8] 1855790 - glibc: Update Intel CET support from upstream 1856398 - glibc: Build with -moutline-atomics on aarch64 1868106 - glibc: Transaction ID collisions cause slow DNS lookups in getaddrinfo 1871385 - glibc: Improve auditing implementation (including DT_AUDIT, and DT_DEPAUDIT) 1871387 - glibc: Improve IBM POWER9 architecture performance 1871394 - glibc: Fix AVX2 off-by-one error in strncmp (swbz#25933) 1871395 - glibc: Improve IBM Z (s390x) Performance 1871396 - glibc: Improve use of static TLS surplus for optimizations. Package List:
Red Hat Enterprise Linux AppStream (v. 8):
aarch64: compat-libpthread-nonshared-2.28-151.el8.aarch64.rpm glibc-debuginfo-2.28-151.el8.aarch64.rpm glibc-utils-2.28-151.el8.aarch64.rpm
ppc64le: compat-libpthread-nonshared-2.28-151.el8.ppc64le.rpm glibc-debuginfo-2.28-151.el8.ppc64le.rpm glibc-debuginfo-common-2.28-151.el8.ppc64le.rpm glibc-utils-2.28-151.el8.ppc64le.rpm
s390x: compat-libpthread-nonshared-2.28-151.el8.s390x.rpm glibc-debuginfo-2.28-151.el8.s390x.rpm glibc-debuginfo-common-2.28-151.el8.s390x.rpm glibc-utils-2.28-151.el8.s390x.rpm
x86_64: compat-libpthread-nonshared-2.28-151.el8.x86_64.rpm glibc-debuginfo-2.28-151.el8.x86_64.rpm glibc-debuginfo-common-2.28-151.el8.x86_64.rpm glibc-utils-2.28-151.el8.x86_64.rpm
Red Hat Enterprise Linux BaseOS (v. 8):
Source: glibc-2.28-151.el8.src.rpm
aarch64: glibc-2.28-151.el8.aarch64.rpm glibc-all-langpacks-2.28-151.el8.aarch64.rpm glibc-common-2.28-151.el8.aarch64.rpm glibc-debuginfo-2.28-151.el8.aarch64.rpm glibc-devel-2.28-151.el8.aarch64.rpm glibc-headers-2.28-151.el8.aarch64.rpm glibc-langpack-aa-2.28-151.el8.aarch64.rpm glibc-langpack-af-2.28-151.el8.aarch64.rpm glibc-langpack-agr-2.28-151.el8.aarch64.rpm glibc-langpack-ak-2.28-151.el8.aarch64.rpm glibc-langpack-am-2.28-151.el8.aarch64.rpm glibc-langpack-an-2.28-151.el8.aarch64.rpm glibc-langpack-anp-2.28-151.el8.aarch64.rpm glibc-langpack-ar-2.28-151.el8.aarch64.rpm glibc-langpack-as-2.28-151.el8.aarch64.rpm glibc-langpack-ast-2.28-151.el8.aarch64.rpm glibc-langpack-ayc-2.28-151.el8.aarch64.rpm glibc-langpack-az-2.28-151.el8.aarch64.rpm glibc-langpack-be-2.28-151.el8.aarch64.rpm glibc-langpack-bem-2.28-151.el8.aarch64.rpm glibc-langpack-ber-2.28-151.el8.aarch64.rpm glibc-langpack-bg-2.28-151.el8.aarch64.rpm glibc-langpack-bhb-2.28-151.el8.aarch64.rpm glibc-langpack-bho-2.28-151.el8.aarch64.rpm glibc-langpack-bi-2.28-151.el8.aarch64.rpm glibc-langpack-bn-2.28-151.el8.aarch64.rpm glibc-langpack-bo-2.28-151.el8.aarch64.rpm glibc-langpack-br-2.28-151.el8.aarch64.rpm glibc-langpack-brx-2.28-151.el8.aarch64.rpm glibc-langpack-bs-2.28-151.el8.aarch64.rpm glibc-langpack-byn-2.28-151.el8.aarch64.rpm glibc-langpack-ca-2.28-151.el8.aarch64.rpm glibc-langpack-ce-2.28-151.el8.aarch64.rpm glibc-langpack-chr-2.28-151.el8.aarch64.rpm glibc-langpack-cmn-2.28-151.el8.aarch64.rpm glibc-langpack-crh-2.28-151.el8.aarch64.rpm glibc-langpack-cs-2.28-151.el8.aarch64.rpm glibc-langpack-csb-2.28-151.el8.aarch64.rpm glibc-langpack-cv-2.28-151.el8.aarch64.rpm glibc-langpack-cy-2.28-151.el8.aarch64.rpm glibc-langpack-da-2.28-151.el8.aarch64.rpm glibc-langpack-de-2.28-151.el8.aarch64.rpm glibc-langpack-doi-2.28-151.el8.aarch64.rpm glibc-langpack-dsb-2.28-151.el8.aarch64.rpm glibc-langpack-dv-2.28-151.el8.aarch64.rpm glibc-langpack-dz-2.28-151.el8.aarch64.rpm glibc-langpack-el-2.28-151.el8.aarch64.rpm glibc-langpack-en-2.28-151.el8.aarch64.rpm glibc-langpack-eo-2.28-151.el8.aarch64.rpm glibc-langpack-es-2.28-151.el8.aarch64.rpm glibc-langpack-et-2.28-151.el8.aarch64.rpm glibc-langpack-eu-2.28-151.el8.aarch64.rpm glibc-langpack-fa-2.28-151.el8.aarch64.rpm glibc-langpack-ff-2.28-151.el8.aarch64.rpm glibc-langpack-fi-2.28-151.el8.aarch64.rpm glibc-langpack-fil-2.28-151.el8.aarch64.rpm glibc-langpack-fo-2.28-151.el8.aarch64.rpm glibc-langpack-fr-2.28-151.el8.aarch64.rpm glibc-langpack-fur-2.28-151.el8.aarch64.rpm glibc-langpack-fy-2.28-151.el8.aarch64.rpm glibc-langpack-ga-2.28-151.el8.aarch64.rpm glibc-langpack-gd-2.28-151.el8.aarch64.rpm glibc-langpack-gez-2.28-151.el8.aarch64.rpm glibc-langpack-gl-2.28-151.el8.aarch64.rpm glibc-langpack-gu-2.28-151.el8.aarch64.rpm glibc-langpack-gv-2.28-151.el8.aarch64.rpm glibc-langpack-ha-2.28-151.el8.aarch64.rpm glibc-langpack-hak-2.28-151.el8.aarch64.rpm glibc-langpack-he-2.28-151.el8.aarch64.rpm glibc-langpack-hi-2.28-151.el8.aarch64.rpm glibc-langpack-hif-2.28-151.el8.aarch64.rpm glibc-langpack-hne-2.28-151.el8.aarch64.rpm glibc-langpack-hr-2.28-151.el8.aarch64.rpm glibc-langpack-hsb-2.28-151.el8.aarch64.rpm glibc-langpack-ht-2.28-151.el8.aarch64.rpm glibc-langpack-hu-2.28-151.el8.aarch64.rpm glibc-langpack-hy-2.28-151.el8.aarch64.rpm glibc-langpack-ia-2.28-151.el8.aarch64.rpm glibc-langpack-id-2.28-151.el8.aarch64.rpm glibc-langpack-ig-2.28-151.el8.aarch64.rpm glibc-langpack-ik-2.28-151.el8.aarch64.rpm glibc-langpack-is-2.28-151.el8.aarch64.rpm glibc-langpack-it-2.28-151.el8.aarch64.rpm glibc-langpack-iu-2.28-151.el8.aarch64.rpm glibc-langpack-ja-2.28-151.el8.aarch64.rpm glibc-langpack-ka-2.28-151.el8.aarch64.rpm glibc-langpack-kab-2.28-151.el8.aarch64.rpm glibc-langpack-kk-2.28-151.el8.aarch64.rpm glibc-langpack-kl-2.28-151.el8.aarch64.rpm glibc-langpack-km-2.28-151.el8.aarch64.rpm glibc-langpack-kn-2.28-151.el8.aarch64.rpm glibc-langpack-ko-2.28-151.el8.aarch64.rpm glibc-langpack-kok-2.28-151.el8.aarch64.rpm glibc-langpack-ks-2.28-151.el8.aarch64.rpm glibc-langpack-ku-2.28-151.el8.aarch64.rpm glibc-langpack-kw-2.28-151.el8.aarch64.rpm glibc-langpack-ky-2.28-151.el8.aarch64.rpm glibc-langpack-lb-2.28-151.el8.aarch64.rpm glibc-langpack-lg-2.28-151.el8.aarch64.rpm glibc-langpack-li-2.28-151.el8.aarch64.rpm glibc-langpack-lij-2.28-151.el8.aarch64.rpm glibc-langpack-ln-2.28-151.el8.aarch64.rpm glibc-langpack-lo-2.28-151.el8.aarch64.rpm glibc-langpack-lt-2.28-151.el8.aarch64.rpm glibc-langpack-lv-2.28-151.el8.aarch64.rpm glibc-langpack-lzh-2.28-151.el8.aarch64.rpm glibc-langpack-mag-2.28-151.el8.aarch64.rpm glibc-langpack-mai-2.28-151.el8.aarch64.rpm glibc-langpack-mfe-2.28-151.el8.aarch64.rpm glibc-langpack-mg-2.28-151.el8.aarch64.rpm glibc-langpack-mhr-2.28-151.el8.aarch64.rpm glibc-langpack-mi-2.28-151.el8.aarch64.rpm glibc-langpack-miq-2.28-151.el8.aarch64.rpm glibc-langpack-mjw-2.28-151.el8.aarch64.rpm glibc-langpack-mk-2.28-151.el8.aarch64.rpm glibc-langpack-ml-2.28-151.el8.aarch64.rpm glibc-langpack-mn-2.28-151.el8.aarch64.rpm glibc-langpack-mni-2.28-151.el8.aarch64.rpm glibc-langpack-mr-2.28-151.el8.aarch64.rpm glibc-langpack-ms-2.28-151.el8.aarch64.rpm glibc-langpack-mt-2.28-151.el8.aarch64.rpm glibc-langpack-my-2.28-151.el8.aarch64.rpm glibc-langpack-nan-2.28-151.el8.aarch64.rpm glibc-langpack-nb-2.28-151.el8.aarch64.rpm glibc-langpack-nds-2.28-151.el8.aarch64.rpm glibc-langpack-ne-2.28-151.el8.aarch64.rpm glibc-langpack-nhn-2.28-151.el8.aarch64.rpm glibc-langpack-niu-2.28-151.el8.aarch64.rpm glibc-langpack-nl-2.28-151.el8.aarch64.rpm glibc-langpack-nn-2.28-151.el8.aarch64.rpm glibc-langpack-nr-2.28-151.el8.aarch64.rpm glibc-langpack-nso-2.28-151.el8.aarch64.rpm glibc-langpack-oc-2.28-151.el8.aarch64.rpm glibc-langpack-om-2.28-151.el8.aarch64.rpm glibc-langpack-or-2.28-151.el8.aarch64.rpm glibc-langpack-os-2.28-151.el8.aarch64.rpm glibc-langpack-pa-2.28-151.el8.aarch64.rpm glibc-langpack-pap-2.28-151.el8.aarch64.rpm glibc-langpack-pl-2.28-151.el8.aarch64.rpm glibc-langpack-ps-2.28-151.el8.aarch64.rpm glibc-langpack-pt-2.28-151.el8.aarch64.rpm glibc-langpack-quz-2.28-151.el8.aarch64.rpm glibc-langpack-raj-2.28-151.el8.aarch64.rpm glibc-langpack-ro-2.28-151.el8.aarch64.rpm glibc-langpack-ru-2.28-151.el8.aarch64.rpm glibc-langpack-rw-2.28-151.el8.aarch64.rpm glibc-langpack-sa-2.28-151.el8.aarch64.rpm glibc-langpack-sah-2.28-151.el8.aarch64.rpm glibc-langpack-sat-2.28-151.el8.aarch64.rpm glibc-langpack-sc-2.28-151.el8.aarch64.rpm glibc-langpack-sd-2.28-151.el8.aarch64.rpm glibc-langpack-se-2.28-151.el8.aarch64.rpm glibc-langpack-sgs-2.28-151.el8.aarch64.rpm glibc-langpack-shn-2.28-151.el8.aarch64.rpm glibc-langpack-shs-2.28-151.el8.aarch64.rpm glibc-langpack-si-2.28-151.el8.aarch64.rpm glibc-langpack-sid-2.28-151.el8.aarch64.rpm glibc-langpack-sk-2.28-151.el8.aarch64.rpm glibc-langpack-sl-2.28-151.el8.aarch64.rpm glibc-langpack-sm-2.28-151.el8.aarch64.rpm glibc-langpack-so-2.28-151.el8.aarch64.rpm glibc-langpack-sq-2.28-151.el8.aarch64.rpm glibc-langpack-sr-2.28-151.el8.aarch64.rpm glibc-langpack-ss-2.28-151.el8.aarch64.rpm glibc-langpack-st-2.28-151.el8.aarch64.rpm glibc-langpack-sv-2.28-151.el8.aarch64.rpm glibc-langpack-sw-2.28-151.el8.aarch64.rpm glibc-langpack-szl-2.28-151.el8.aarch64.rpm glibc-langpack-ta-2.28-151.el8.aarch64.rpm glibc-langpack-tcy-2.28-151.el8.aarch64.rpm glibc-langpack-te-2.28-151.el8.aarch64.rpm glibc-langpack-tg-2.28-151.el8.aarch64.rpm glibc-langpack-th-2.28-151.el8.aarch64.rpm glibc-langpack-the-2.28-151.el8.aarch64.rpm glibc-langpack-ti-2.28-151.el8.aarch64.rpm glibc-langpack-tig-2.28-151.el8.aarch64.rpm glibc-langpack-tk-2.28-151.el8.aarch64.rpm glibc-langpack-tl-2.28-151.el8.aarch64.rpm glibc-langpack-tn-2.28-151.el8.aarch64.rpm glibc-langpack-to-2.28-151.el8.aarch64.rpm glibc-langpack-tpi-2.28-151.el8.aarch64.rpm glibc-langpack-tr-2.28-151.el8.aarch64.rpm glibc-langpack-ts-2.28-151.el8.aarch64.rpm glibc-langpack-tt-2.28-151.el8.aarch64.rpm glibc-langpack-ug-2.28-151.el8.aarch64.rpm glibc-langpack-uk-2.28-151.el8.aarch64.rpm glibc-langpack-unm-2.28-151.el8.aarch64.rpm glibc-langpack-ur-2.28-151.el8.aarch64.rpm glibc-langpack-uz-2.28-151.el8.aarch64.rpm glibc-langpack-ve-2.28-151.el8.aarch64.rpm glibc-langpack-vi-2.28-151.el8.aarch64.rpm glibc-langpack-wa-2.28-151.el8.aarch64.rpm glibc-langpack-wae-2.28-151.el8.aarch64.rpm glibc-langpack-wal-2.28-151.el8.aarch64.rpm glibc-langpack-wo-2.28-151.el8.aarch64.rpm glibc-langpack-xh-2.28-151.el8.aarch64.rpm glibc-langpack-yi-2.28-151.el8.aarch64.rpm glibc-langpack-yo-2.28-151.el8.aarch64.rpm glibc-langpack-yue-2.28-151.el8.aarch64.rpm glibc-langpack-yuw-2.28-151.el8.aarch64.rpm glibc-langpack-zh-2.28-151.el8.aarch64.rpm glibc-langpack-zu-2.28-151.el8.aarch64.rpm glibc-locale-source-2.28-151.el8.aarch64.rpm glibc-minimal-langpack-2.28-151.el8.aarch64.rpm libnsl-2.28-151.el8.aarch64.rpm nscd-2.28-151.el8.aarch64.rpm nss_db-2.28-151.el8.aarch64.rpm
ppc64le: glibc-2.28-151.el8.ppc64le.rpm glibc-all-langpacks-2.28-151.el8.ppc64le.rpm glibc-common-2.28-151.el8.ppc64le.rpm glibc-debuginfo-2.28-151.el8.ppc64le.rpm glibc-debuginfo-common-2.28-151.el8.ppc64le.rpm glibc-devel-2.28-151.el8.ppc64le.rpm glibc-headers-2.28-151.el8.ppc64le.rpm glibc-langpack-aa-2.28-151.el8.ppc64le.rpm glibc-langpack-af-2.28-151.el8.ppc64le.rpm glibc-langpack-agr-2.28-151.el8.ppc64le.rpm glibc-langpack-ak-2.28-151.el8.ppc64le.rpm glibc-langpack-am-2.28-151.el8.ppc64le.rpm glibc-langpack-an-2.28-151.el8.ppc64le.rpm glibc-langpack-anp-2.28-151.el8.ppc64le.rpm glibc-langpack-ar-2.28-151.el8.ppc64le.rpm glibc-langpack-as-2.28-151.el8.ppc64le.rpm glibc-langpack-ast-2.28-151.el8.ppc64le.rpm glibc-langpack-ayc-2.28-151.el8.ppc64le.rpm glibc-langpack-az-2.28-151.el8.ppc64le.rpm glibc-langpack-be-2.28-151.el8.ppc64le.rpm glibc-langpack-bem-2.28-151.el8.ppc64le.rpm glibc-langpack-ber-2.28-151.el8.ppc64le.rpm glibc-langpack-bg-2.28-151.el8.ppc64le.rpm glibc-langpack-bhb-2.28-151.el8.ppc64le.rpm glibc-langpack-bho-2.28-151.el8.ppc64le.rpm glibc-langpack-bi-2.28-151.el8.ppc64le.rpm glibc-langpack-bn-2.28-151.el8.ppc64le.rpm glibc-langpack-bo-2.28-151.el8.ppc64le.rpm glibc-langpack-br-2.28-151.el8.ppc64le.rpm glibc-langpack-brx-2.28-151.el8.ppc64le.rpm glibc-langpack-bs-2.28-151.el8.ppc64le.rpm glibc-langpack-byn-2.28-151.el8.ppc64le.rpm glibc-langpack-ca-2.28-151.el8.ppc64le.rpm glibc-langpack-ce-2.28-151.el8.ppc64le.rpm glibc-langpack-chr-2.28-151.el8.ppc64le.rpm glibc-langpack-cmn-2.28-151.el8.ppc64le.rpm glibc-langpack-crh-2.28-151.el8.ppc64le.rpm glibc-langpack-cs-2.28-151.el8.ppc64le.rpm glibc-langpack-csb-2.28-151.el8.ppc64le.rpm glibc-langpack-cv-2.28-151.el8.ppc64le.rpm glibc-langpack-cy-2.28-151.el8.ppc64le.rpm glibc-langpack-da-2.28-151.el8.ppc64le.rpm glibc-langpack-de-2.28-151.el8.ppc64le.rpm glibc-langpack-doi-2.28-151.el8.ppc64le.rpm glibc-langpack-dsb-2.28-151.el8.ppc64le.rpm glibc-langpack-dv-2.28-151.el8.ppc64le.rpm glibc-langpack-dz-2.28-151.el8.ppc64le.rpm glibc-langpack-el-2.28-151.el8.ppc64le.rpm glibc-langpack-en-2.28-151.el8.ppc64le.rpm glibc-langpack-eo-2.28-151.el8.ppc64le.rpm glibc-langpack-es-2.28-151.el8.ppc64le.rpm glibc-langpack-et-2.28-151.el8.ppc64le.rpm glibc-langpack-eu-2.28-151.el8.ppc64le.rpm glibc-langpack-fa-2.28-151.el8.ppc64le.rpm glibc-langpack-ff-2.28-151.el8.ppc64le.rpm glibc-langpack-fi-2.28-151.el8.ppc64le.rpm glibc-langpack-fil-2.28-151.el8.ppc64le.rpm glibc-langpack-fo-2.28-151.el8.ppc64le.rpm glibc-langpack-fr-2.28-151.el8.ppc64le.rpm glibc-langpack-fur-2.28-151.el8.ppc64le.rpm glibc-langpack-fy-2.28-151.el8.ppc64le.rpm glibc-langpack-ga-2.28-151.el8.ppc64le.rpm glibc-langpack-gd-2.28-151.el8.ppc64le.rpm glibc-langpack-gez-2.28-151.el8.ppc64le.rpm glibc-langpack-gl-2.28-151.el8.ppc64le.rpm glibc-langpack-gu-2.28-151.el8.ppc64le.rpm glibc-langpack-gv-2.28-151.el8.ppc64le.rpm glibc-langpack-ha-2.28-151.el8.ppc64le.rpm glibc-langpack-hak-2.28-151.el8.ppc64le.rpm glibc-langpack-he-2.28-151.el8.ppc64le.rpm glibc-langpack-hi-2.28-151.el8.ppc64le.rpm glibc-langpack-hif-2.28-151.el8.ppc64le.rpm glibc-langpack-hne-2.28-151.el8.ppc64le.rpm glibc-langpack-hr-2.28-151.el8.ppc64le.rpm glibc-langpack-hsb-2.28-151.el8.ppc64le.rpm glibc-langpack-ht-2.28-151.el8.ppc64le.rpm glibc-langpack-hu-2.28-151.el8.ppc64le.rpm glibc-langpack-hy-2.28-151.el8.ppc64le.rpm glibc-langpack-ia-2.28-151.el8.ppc64le.rpm glibc-langpack-id-2.28-151.el8.ppc64le.rpm glibc-langpack-ig-2.28-151.el8.ppc64le.rpm glibc-langpack-ik-2.28-151.el8.ppc64le.rpm glibc-langpack-is-2.28-151.el8.ppc64le.rpm glibc-langpack-it-2.28-151.el8.ppc64le.rpm glibc-langpack-iu-2.28-151.el8.ppc64le.rpm glibc-langpack-ja-2.28-151.el8.ppc64le.rpm glibc-langpack-ka-2.28-151.el8.ppc64le.rpm glibc-langpack-kab-2.28-151.el8.ppc64le.rpm glibc-langpack-kk-2.28-151.el8.ppc64le.rpm glibc-langpack-kl-2.28-151.el8.ppc64le.rpm glibc-langpack-km-2.28-151.el8.ppc64le.rpm glibc-langpack-kn-2.28-151.el8.ppc64le.rpm glibc-langpack-ko-2.28-151.el8.ppc64le.rpm glibc-langpack-kok-2.28-151.el8.ppc64le.rpm glibc-langpack-ks-2.28-151.el8.ppc64le.rpm glibc-langpack-ku-2.28-151.el8.ppc64le.rpm glibc-langpack-kw-2.28-151.el8.ppc64le.rpm glibc-langpack-ky-2.28-151.el8.ppc64le.rpm glibc-langpack-lb-2.28-151.el8.ppc64le.rpm glibc-langpack-lg-2.28-151.el8.ppc64le.rpm glibc-langpack-li-2.28-151.el8.ppc64le.rpm glibc-langpack-lij-2.28-151.el8.ppc64le.rpm glibc-langpack-ln-2.28-151.el8.ppc64le.rpm glibc-langpack-lo-2.28-151.el8.ppc64le.rpm glibc-langpack-lt-2.28-151.el8.ppc64le.rpm glibc-langpack-lv-2.28-151.el8.ppc64le.rpm glibc-langpack-lzh-2.28-151.el8.ppc64le.rpm glibc-langpack-mag-2.28-151.el8.ppc64le.rpm glibc-langpack-mai-2.28-151.el8.ppc64le.rpm glibc-langpack-mfe-2.28-151.el8.ppc64le.rpm glibc-langpack-mg-2.28-151.el8.ppc64le.rpm glibc-langpack-mhr-2.28-151.el8.ppc64le.rpm glibc-langpack-mi-2.28-151.el8.ppc64le.rpm glibc-langpack-miq-2.28-151.el8.ppc64le.rpm glibc-langpack-mjw-2.28-151.el8.ppc64le.rpm glibc-langpack-mk-2.28-151.el8.ppc64le.rpm glibc-langpack-ml-2.28-151.el8.ppc64le.rpm glibc-langpack-mn-2.28-151.el8.ppc64le.rpm glibc-langpack-mni-2.28-151.el8.ppc64le.rpm glibc-langpack-mr-2.28-151.el8.ppc64le.rpm glibc-langpack-ms-2.28-151.el8.ppc64le.rpm glibc-langpack-mt-2.28-151.el8.ppc64le.rpm glibc-langpack-my-2.28-151.el8.ppc64le.rpm glibc-langpack-nan-2.28-151.el8.ppc64le.rpm glibc-langpack-nb-2.28-151.el8.ppc64le.rpm glibc-langpack-nds-2.28-151.el8.ppc64le.rpm glibc-langpack-ne-2.28-151.el8.ppc64le.rpm glibc-langpack-nhn-2.28-151.el8.ppc64le.rpm glibc-langpack-niu-2.28-151.el8.ppc64le.rpm glibc-langpack-nl-2.28-151.el8.ppc64le.rpm glibc-langpack-nn-2.28-151.el8.ppc64le.rpm glibc-langpack-nr-2.28-151.el8.ppc64le.rpm glibc-langpack-nso-2.28-151.el8.ppc64le.rpm glibc-langpack-oc-2.28-151.el8.ppc64le.rpm glibc-langpack-om-2.28-151.el8.ppc64le.rpm glibc-langpack-or-2.28-151.el8.ppc64le.rpm glibc-langpack-os-2.28-151.el8.ppc64le.rpm glibc-langpack-pa-2.28-151.el8.ppc64le.rpm glibc-langpack-pap-2.28-151.el8.ppc64le.rpm glibc-langpack-pl-2.28-151.el8.ppc64le.rpm glibc-langpack-ps-2.28-151.el8.ppc64le.rpm glibc-langpack-pt-2.28-151.el8.ppc64le.rpm glibc-langpack-quz-2.28-151.el8.ppc64le.rpm glibc-langpack-raj-2.28-151.el8.ppc64le.rpm glibc-langpack-ro-2.28-151.el8.ppc64le.rpm glibc-langpack-ru-2.28-151.el8.ppc64le.rpm glibc-langpack-rw-2.28-151.el8.ppc64le.rpm glibc-langpack-sa-2.28-151.el8.ppc64le.rpm glibc-langpack-sah-2.28-151.el8.ppc64le.rpm glibc-langpack-sat-2.28-151.el8.ppc64le.rpm glibc-langpack-sc-2.28-151.el8.ppc64le.rpm glibc-langpack-sd-2.28-151.el8.ppc64le.rpm glibc-langpack-se-2.28-151.el8.ppc64le.rpm glibc-langpack-sgs-2.28-151.el8.ppc64le.rpm glibc-langpack-shn-2.28-151.el8.ppc64le.rpm glibc-langpack-shs-2.28-151.el8.ppc64le.rpm glibc-langpack-si-2.28-151.el8.ppc64le.rpm glibc-langpack-sid-2.28-151.el8.ppc64le.rpm glibc-langpack-sk-2.28-151.el8.ppc64le.rpm glibc-langpack-sl-2.28-151.el8.ppc64le.rpm glibc-langpack-sm-2.28-151.el8.ppc64le.rpm glibc-langpack-so-2.28-151.el8.ppc64le.rpm glibc-langpack-sq-2.28-151.el8.ppc64le.rpm glibc-langpack-sr-2.28-151.el8.ppc64le.rpm glibc-langpack-ss-2.28-151.el8.ppc64le.rpm glibc-langpack-st-2.28-151.el8.ppc64le.rpm glibc-langpack-sv-2.28-151.el8.ppc64le.rpm glibc-langpack-sw-2.28-151.el8.ppc64le.rpm glibc-langpack-szl-2.28-151.el8.ppc64le.rpm glibc-langpack-ta-2.28-151.el8.ppc64le.rpm glibc-langpack-tcy-2.28-151.el8.ppc64le.rpm glibc-langpack-te-2.28-151.el8.ppc64le.rpm glibc-langpack-tg-2.28-151.el8.ppc64le.rpm glibc-langpack-th-2.28-151.el8.ppc64le.rpm glibc-langpack-the-2.28-151.el8.ppc64le.rpm glibc-langpack-ti-2.28-151.el8.ppc64le.rpm glibc-langpack-tig-2.28-151.el8.ppc64le.rpm glibc-langpack-tk-2.28-151.el8.ppc64le.rpm glibc-langpack-tl-2.28-151.el8.ppc64le.rpm glibc-langpack-tn-2.28-151.el8.ppc64le.rpm glibc-langpack-to-2.28-151.el8.ppc64le.rpm glibc-langpack-tpi-2.28-151.el8.ppc64le.rpm glibc-langpack-tr-2.28-151.el8.ppc64le.rpm glibc-langpack-ts-2.28-151.el8.ppc64le.rpm glibc-langpack-tt-2.28-151.el8.ppc64le.rpm glibc-langpack-ug-2.28-151.el8.ppc64le.rpm glibc-langpack-uk-2.28-151.el8.ppc64le.rpm glibc-langpack-unm-2.28-151.el8.ppc64le.rpm glibc-langpack-ur-2.28-151.el8.ppc64le.rpm glibc-langpack-uz-2.28-151.el8.ppc64le.rpm glibc-langpack-ve-2.28-151.el8.ppc64le.rpm glibc-langpack-vi-2.28-151.el8.ppc64le.rpm glibc-langpack-wa-2.28-151.el8.ppc64le.rpm glibc-langpack-wae-2.28-151.el8.ppc64le.rpm glibc-langpack-wal-2.28-151.el8.ppc64le.rpm glibc-langpack-wo-2.28-151.el8.ppc64le.rpm glibc-langpack-xh-2.28-151.el8.ppc64le.rpm glibc-langpack-yi-2.28-151.el8.ppc64le.rpm glibc-langpack-yo-2.28-151.el8.ppc64le.rpm glibc-langpack-yue-2.28-151.el8.ppc64le.rpm glibc-langpack-yuw-2.28-151.el8.ppc64le.rpm glibc-langpack-zh-2.28-151.el8.ppc64le.rpm glibc-langpack-zu-2.28-151.el8.ppc64le.rpm glibc-locale-source-2.28-151.el8.ppc64le.rpm glibc-minimal-langpack-2.28-151.el8.ppc64le.rpm libnsl-2.28-151.el8.ppc64le.rpm nscd-2.28-151.el8.ppc64le.rpm nss_db-2.28-151.el8.ppc64le.rpm
s390x: glibc-2.28-151.el8.s390x.rpm glibc-all-langpacks-2.28-151.el8.s390x.rpm glibc-common-2.28-151.el8.s390x.rpm glibc-debuginfo-2.28-151.el8.s390x.rpm glibc-debuginfo-common-2.28-151.el8.s390x.rpm glibc-devel-2.28-151.el8.s390x.rpm glibc-headers-2.28-151.el8.s390x.rpm glibc-langpack-aa-2.28-151.el8.s390x.rpm glibc-langpack-af-2.28-151.el8.s390x.rpm glibc-langpack-agr-2.28-151.el8.s390x.rpm glibc-langpack-ak-2.28-151.el8.s390x.rpm glibc-langpack-am-2.28-151.el8.s390x.rpm glibc-langpack-an-2.28-151.el8.s390x.rpm glibc-langpack-anp-2.28-151.el8.s390x.rpm glibc-langpack-ar-2.28-151.el8.s390x.rpm glibc-langpack-as-2.28-151.el8.s390x.rpm glibc-langpack-ast-2.28-151.el8.s390x.rpm glibc-langpack-ayc-2.28-151.el8.s390x.rpm glibc-langpack-az-2.28-151.el8.s390x.rpm glibc-langpack-be-2.28-151.el8.s390x.rpm glibc-langpack-bem-2.28-151.el8.s390x.rpm glibc-langpack-ber-2.28-151.el8.s390x.rpm glibc-langpack-bg-2.28-151.el8.s390x.rpm glibc-langpack-bhb-2.28-151.el8.s390x.rpm glibc-langpack-bho-2.28-151.el8.s390x.rpm glibc-langpack-bi-2.28-151.el8.s390x.rpm glibc-langpack-bn-2.28-151.el8.s390x.rpm glibc-langpack-bo-2.28-151.el8.s390x.rpm glibc-langpack-br-2.28-151.el8.s390x.rpm glibc-langpack-brx-2.28-151.el8.s390x.rpm glibc-langpack-bs-2.28-151.el8.s390x.rpm glibc-langpack-byn-2.28-151.el8.s390x.rpm glibc-langpack-ca-2.28-151.el8.s390x.rpm glibc-langpack-ce-2.28-151.el8.s390x.rpm glibc-langpack-chr-2.28-151.el8.s390x.rpm glibc-langpack-cmn-2.28-151.el8.s390x.rpm glibc-langpack-crh-2.28-151.el8.s390x.rpm glibc-langpack-cs-2.28-151.el8.s390x.rpm glibc-langpack-csb-2.28-151.el8.s390x.rpm glibc-langpack-cv-2.28-151.el8.s390x.rpm glibc-langpack-cy-2.28-151.el8.s390x.rpm glibc-langpack-da-2.28-151.el8.s390x.rpm glibc-langpack-de-2.28-151.el8.s390x.rpm glibc-langpack-doi-2.28-151.el8.s390x.rpm glibc-langpack-dsb-2.28-151.el8.s390x.rpm glibc-langpack-dv-2.28-151.el8.s390x.rpm glibc-langpack-dz-2.28-151.el8.s390x.rpm glibc-langpack-el-2.28-151.el8.s390x.rpm glibc-langpack-en-2.28-151.el8.s390x.rpm glibc-langpack-eo-2.28-151.el8.s390x.rpm glibc-langpack-es-2.28-151.el8.s390x.rpm glibc-langpack-et-2.28-151.el8.s390x.rpm glibc-langpack-eu-2.28-151.el8.s390x.rpm glibc-langpack-fa-2.28-151.el8.s390x.rpm glibc-langpack-ff-2.28-151.el8.s390x.rpm glibc-langpack-fi-2.28-151.el8.s390x.rpm glibc-langpack-fil-2.28-151.el8.s390x.rpm glibc-langpack-fo-2.28-151.el8.s390x.rpm glibc-langpack-fr-2.28-151.el8.s390x.rpm glibc-langpack-fur-2.28-151.el8.s390x.rpm glibc-langpack-fy-2.28-151.el8.s390x.rpm glibc-langpack-ga-2.28-151.el8.s390x.rpm glibc-langpack-gd-2.28-151.el8.s390x.rpm glibc-langpack-gez-2.28-151.el8.s390x.rpm glibc-langpack-gl-2.28-151.el8.s390x.rpm glibc-langpack-gu-2.28-151.el8.s390x.rpm glibc-langpack-gv-2.28-151.el8.s390x.rpm glibc-langpack-ha-2.28-151.el8.s390x.rpm glibc-langpack-hak-2.28-151.el8.s390x.rpm glibc-langpack-he-2.28-151.el8.s390x.rpm glibc-langpack-hi-2.28-151.el8.s390x.rpm glibc-langpack-hif-2.28-151.el8.s390x.rpm glibc-langpack-hne-2.28-151.el8.s390x.rpm glibc-langpack-hr-2.28-151.el8.s390x.rpm glibc-langpack-hsb-2.28-151.el8.s390x.rpm glibc-langpack-ht-2.28-151.el8.s390x.rpm glibc-langpack-hu-2.28-151.el8.s390x.rpm glibc-langpack-hy-2.28-151.el8.s390x.rpm glibc-langpack-ia-2.28-151.el8.s390x.rpm glibc-langpack-id-2.28-151.el8.s390x.rpm glibc-langpack-ig-2.28-151.el8.s390x.rpm glibc-langpack-ik-2.28-151.el8.s390x.rpm glibc-langpack-is-2.28-151.el8.s390x.rpm glibc-langpack-it-2.28-151.el8.s390x.rpm glibc-langpack-iu-2.28-151.el8.s390x.rpm glibc-langpack-ja-2.28-151.el8.s390x.rpm glibc-langpack-ka-2.28-151.el8.s390x.rpm glibc-langpack-kab-2.28-151.el8.s390x.rpm glibc-langpack-kk-2.28-151.el8.s390x.rpm glibc-langpack-kl-2.28-151.el8.s390x.rpm glibc-langpack-km-2.28-151.el8.s390x.rpm glibc-langpack-kn-2.28-151.el8.s390x.rpm glibc-langpack-ko-2.28-151.el8.s390x.rpm glibc-langpack-kok-2.28-151.el8.s390x.rpm glibc-langpack-ks-2.28-151.el8.s390x.rpm glibc-langpack-ku-2.28-151.el8.s390x.rpm glibc-langpack-kw-2.28-151.el8.s390x.rpm glibc-langpack-ky-2.28-151.el8.s390x.rpm glibc-langpack-lb-2.28-151.el8.s390x.rpm glibc-langpack-lg-2.28-151.el8.s390x.rpm glibc-langpack-li-2.28-151.el8.s390x.rpm glibc-langpack-lij-2.28-151.el8.s390x.rpm glibc-langpack-ln-2.28-151.el8.s390x.rpm glibc-langpack-lo-2.28-151.el8.s390x.rpm glibc-langpack-lt-2.28-151.el8.s390x.rpm glibc-langpack-lv-2.28-151.el8.s390x.rpm glibc-langpack-lzh-2.28-151.el8.s390x.rpm glibc-langpack-mag-2.28-151.el8.s390x.rpm glibc-langpack-mai-2.28-151.el8.s390x.rpm glibc-langpack-mfe-2.28-151.el8.s390x.rpm glibc-langpack-mg-2.28-151.el8.s390x.rpm glibc-langpack-mhr-2.28-151.el8.s390x.rpm glibc-langpack-mi-2.28-151.el8.s390x.rpm glibc-langpack-miq-2.28-151.el8.s390x.rpm glibc-langpack-mjw-2.28-151.el8.s390x.rpm glibc-langpack-mk-2.28-151.el8.s390x.rpm glibc-langpack-ml-2.28-151.el8.s390x.rpm glibc-langpack-mn-2.28-151.el8.s390x.rpm glibc-langpack-mni-2.28-151.el8.s390x.rpm glibc-langpack-mr-2.28-151.el8.s390x.rpm glibc-langpack-ms-2.28-151.el8.s390x.rpm glibc-langpack-mt-2.28-151.el8.s390x.rpm glibc-langpack-my-2.28-151.el8.s390x.rpm glibc-langpack-nan-2.28-151.el8.s390x.rpm glibc-langpack-nb-2.28-151.el8.s390x.rpm glibc-langpack-nds-2.28-151.el8.s390x.rpm glibc-langpack-ne-2.28-151.el8.s390x.rpm glibc-langpack-nhn-2.28-151.el8.s390x.rpm glibc-langpack-niu-2.28-151.el8.s390x.rpm glibc-langpack-nl-2.28-151.el8.s390x.rpm glibc-langpack-nn-2.28-151.el8.s390x.rpm glibc-langpack-nr-2.28-151.el8.s390x.rpm glibc-langpack-nso-2.28-151.el8.s390x.rpm glibc-langpack-oc-2.28-151.el8.s390x.rpm glibc-langpack-om-2.28-151.el8.s390x.rpm glibc-langpack-or-2.28-151.el8.s390x.rpm glibc-langpack-os-2.28-151.el8.s390x.rpm glibc-langpack-pa-2.28-151.el8.s390x.rpm glibc-langpack-pap-2.28-151.el8.s390x.rpm glibc-langpack-pl-2.28-151.el8.s390x.rpm glibc-langpack-ps-2.28-151.el8.s390x.rpm glibc-langpack-pt-2.28-151.el8.s390x.rpm glibc-langpack-quz-2.28-151.el8.s390x.rpm glibc-langpack-raj-2.28-151.el8.s390x.rpm glibc-langpack-ro-2.28-151.el8.s390x.rpm glibc-langpack-ru-2.28-151.el8.s390x.rpm glibc-langpack-rw-2.28-151.el8.s390x.rpm glibc-langpack-sa-2.28-151.el8.s390x.rpm glibc-langpack-sah-2.28-151.el8.s390x.rpm glibc-langpack-sat-2.28-151.el8.s390x.rpm glibc-langpack-sc-2.28-151.el8.s390x.rpm glibc-langpack-sd-2.28-151.el8.s390x.rpm glibc-langpack-se-2.28-151.el8.s390x.rpm glibc-langpack-sgs-2.28-151.el8.s390x.rpm glibc-langpack-shn-2.28-151.el8.s390x.rpm glibc-langpack-shs-2.28-151.el8.s390x.rpm glibc-langpack-si-2.28-151.el8.s390x.rpm glibc-langpack-sid-2.28-151.el8.s390x.rpm glibc-langpack-sk-2.28-151.el8.s390x.rpm glibc-langpack-sl-2.28-151.el8.s390x.rpm glibc-langpack-sm-2.28-151.el8.s390x.rpm glibc-langpack-so-2.28-151.el8.s390x.rpm glibc-langpack-sq-2.28-151.el8.s390x.rpm glibc-langpack-sr-2.28-151.el8.s390x.rpm glibc-langpack-ss-2.28-151.el8.s390x.rpm glibc-langpack-st-2.28-151.el8.s390x.rpm glibc-langpack-sv-2.28-151.el8.s390x.rpm glibc-langpack-sw-2.28-151.el8.s390x.rpm glibc-langpack-szl-2.28-151.el8.s390x.rpm glibc-langpack-ta-2.28-151.el8.s390x.rpm glibc-langpack-tcy-2.28-151.el8.s390x.rpm glibc-langpack-te-2.28-151.el8.s390x.rpm glibc-langpack-tg-2.28-151.el8.s390x.rpm glibc-langpack-th-2.28-151.el8.s390x.rpm glibc-langpack-the-2.28-151.el8.s390x.rpm glibc-langpack-ti-2.28-151.el8.s390x.rpm glibc-langpack-tig-2.28-151.el8.s390x.rpm glibc-langpack-tk-2.28-151.el8.s390x.rpm glibc-langpack-tl-2.28-151.el8.s390x.rpm glibc-langpack-tn-2.28-151.el8.s390x.rpm glibc-langpack-to-2.28-151.el8.s390x.rpm glibc-langpack-tpi-2.28-151.el8.s390x.rpm glibc-langpack-tr-2.28-151.el8.s390x.rpm glibc-langpack-ts-2.28-151.el8.s390x.rpm glibc-langpack-tt-2.28-151.el8.s390x.rpm glibc-langpack-ug-2.28-151.el8.s390x.rpm glibc-langpack-uk-2.28-151.el8.s390x.rpm glibc-langpack-unm-2.28-151.el8.s390x.rpm glibc-langpack-ur-2.28-151.el8.s390x.rpm glibc-langpack-uz-2.28-151.el8.s390x.rpm glibc-langpack-ve-2.28-151.el8.s390x.rpm glibc-langpack-vi-2.28-151.el8.s390x.rpm glibc-langpack-wa-2.28-151.el8.s390x.rpm glibc-langpack-wae-2.28-151.el8.s390x.rpm glibc-langpack-wal-2.28-151.el8.s390x.rpm glibc-langpack-wo-2.28-151.el8.s390x.rpm glibc-langpack-xh-2.28-151.el8.s390x.rpm glibc-langpack-yi-2.28-151.el8.s390x.rpm glibc-langpack-yo-2.28-151.el8.s390x.rpm glibc-langpack-yue-2.28-151.el8.s390x.rpm glibc-langpack-yuw-2.28-151.el8.s390x.rpm glibc-langpack-zh-2.28-151.el8.s390x.rpm glibc-langpack-zu-2.28-151.el8.s390x.rpm glibc-locale-source-2.28-151.el8.s390x.rpm glibc-minimal-langpack-2.28-151.el8.s390x.rpm libnsl-2.28-151.el8.s390x.rpm nscd-2.28-151.el8.s390x.rpm nss_db-2.28-151.el8.s390x.rpm
x86_64: glibc-2.28-151.el8.i686.rpm glibc-2.28-151.el8.x86_64.rpm glibc-all-langpacks-2.28-151.el8.x86_64.rpm glibc-common-2.28-151.el8.x86_64.rpm glibc-debuginfo-2.28-151.el8.i686.rpm glibc-debuginfo-2.28-151.el8.x86_64.rpm glibc-debuginfo-common-2.28-151.el8.i686.rpm glibc-debuginfo-common-2.28-151.el8.x86_64.rpm glibc-devel-2.28-151.el8.i686.rpm glibc-devel-2.28-151.el8.x86_64.rpm glibc-headers-2.28-151.el8.i686.rpm glibc-headers-2.28-151.el8.x86_64.rpm glibc-langpack-aa-2.28-151.el8.x86_64.rpm glibc-langpack-af-2.28-151.el8.x86_64.rpm glibc-langpack-agr-2.28-151.el8.x86_64.rpm glibc-langpack-ak-2.28-151.el8.x86_64.rpm glibc-langpack-am-2.28-151.el8.x86_64.rpm glibc-langpack-an-2.28-151.el8.x86_64.rpm glibc-langpack-anp-2.28-151.el8.x86_64.rpm glibc-langpack-ar-2.28-151.el8.x86_64.rpm glibc-langpack-as-2.28-151.el8.x86_64.rpm glibc-langpack-ast-2.28-151.el8.x86_64.rpm glibc-langpack-ayc-2.28-151.el8.x86_64.rpm glibc-langpack-az-2.28-151.el8.x86_64.rpm glibc-langpack-be-2.28-151.el8.x86_64.rpm glibc-langpack-bem-2.28-151.el8.x86_64.rpm glibc-langpack-ber-2.28-151.el8.x86_64.rpm glibc-langpack-bg-2.28-151.el8.x86_64.rpm glibc-langpack-bhb-2.28-151.el8.x86_64.rpm glibc-langpack-bho-2.28-151.el8.x86_64.rpm glibc-langpack-bi-2.28-151.el8.x86_64.rpm glibc-langpack-bn-2.28-151.el8.x86_64.rpm glibc-langpack-bo-2.28-151.el8.x86_64.rpm glibc-langpack-br-2.28-151.el8.x86_64.rpm glibc-langpack-brx-2.28-151.el8.x86_64.rpm glibc-langpack-bs-2.28-151.el8.x86_64.rpm glibc-langpack-byn-2.28-151.el8.x86_64.rpm glibc-langpack-ca-2.28-151.el8.x86_64.rpm glibc-langpack-ce-2.28-151.el8.x86_64.rpm glibc-langpack-chr-2.28-151.el8.x86_64.rpm glibc-langpack-cmn-2.28-151.el8.x86_64.rpm glibc-langpack-crh-2.28-151.el8.x86_64.rpm glibc-langpack-cs-2.28-151.el8.x86_64.rpm glibc-langpack-csb-2.28-151.el8.x86_64.rpm glibc-langpack-cv-2.28-151.el8.x86_64.rpm glibc-langpack-cy-2.28-151.el8.x86_64.rpm glibc-langpack-da-2.28-151.el8.x86_64.rpm glibc-langpack-de-2.28-151.el8.x86_64.rpm glibc-langpack-doi-2.28-151.el8.x86_64.rpm glibc-langpack-dsb-2.28-151.el8.x86_64.rpm glibc-langpack-dv-2.28-151.el8.x86_64.rpm glibc-langpack-dz-2.28-151.el8.x86_64.rpm glibc-langpack-el-2.28-151.el8.x86_64.rpm glibc-langpack-en-2.28-151.el8.x86_64.rpm glibc-langpack-eo-2.28-151.el8.x86_64.rpm glibc-langpack-es-2.28-151.el8.x86_64.rpm glibc-langpack-et-2.28-151.el8.x86_64.rpm glibc-langpack-eu-2.28-151.el8.x86_64.rpm glibc-langpack-fa-2.28-151.el8.x86_64.rpm glibc-langpack-ff-2.28-151.el8.x86_64.rpm glibc-langpack-fi-2.28-151.el8.x86_64.rpm glibc-langpack-fil-2.28-151.el8.x86_64.rpm glibc-langpack-fo-2.28-151.el8.x86_64.rpm glibc-langpack-fr-2.28-151.el8.x86_64.rpm glibc-langpack-fur-2.28-151.el8.x86_64.rpm glibc-langpack-fy-2.28-151.el8.x86_64.rpm glibc-langpack-ga-2.28-151.el8.x86_64.rpm glibc-langpack-gd-2.28-151.el8.x86_64.rpm glibc-langpack-gez-2.28-151.el8.x86_64.rpm glibc-langpack-gl-2.28-151.el8.x86_64.rpm glibc-langpack-gu-2.28-151.el8.x86_64.rpm glibc-langpack-gv-2.28-151.el8.x86_64.rpm glibc-langpack-ha-2.28-151.el8.x86_64.rpm glibc-langpack-hak-2.28-151.el8.x86_64.rpm glibc-langpack-he-2.28-151.el8.x86_64.rpm glibc-langpack-hi-2.28-151.el8.x86_64.rpm glibc-langpack-hif-2.28-151.el8.x86_64.rpm glibc-langpack-hne-2.28-151.el8.x86_64.rpm glibc-langpack-hr-2.28-151.el8.x86_64.rpm glibc-langpack-hsb-2.28-151.el8.x86_64.rpm glibc-langpack-ht-2.28-151.el8.x86_64.rpm glibc-langpack-hu-2.28-151.el8.x86_64.rpm glibc-langpack-hy-2.28-151.el8.x86_64.rpm glibc-langpack-ia-2.28-151.el8.x86_64.rpm glibc-langpack-id-2.28-151.el8.x86_64.rpm glibc-langpack-ig-2.28-151.el8.x86_64.rpm glibc-langpack-ik-2.28-151.el8.x86_64.rpm glibc-langpack-is-2.28-151.el8.x86_64.rpm glibc-langpack-it-2.28-151.el8.x86_64.rpm glibc-langpack-iu-2.28-151.el8.x86_64.rpm glibc-langpack-ja-2.28-151.el8.x86_64.rpm glibc-langpack-ka-2.28-151.el8.x86_64.rpm glibc-langpack-kab-2.28-151.el8.x86_64.rpm glibc-langpack-kk-2.28-151.el8.x86_64.rpm glibc-langpack-kl-2.28-151.el8.x86_64.rpm glibc-langpack-km-2.28-151.el8.x86_64.rpm glibc-langpack-kn-2.28-151.el8.x86_64.rpm glibc-langpack-ko-2.28-151.el8.x86_64.rpm glibc-langpack-kok-2.28-151.el8.x86_64.rpm glibc-langpack-ks-2.28-151.el8.x86_64.rpm glibc-langpack-ku-2.28-151.el8.x86_64.rpm glibc-langpack-kw-2.28-151.el8.x86_64.rpm glibc-langpack-ky-2.28-151.el8.x86_64.rpm glibc-langpack-lb-2.28-151.el8.x86_64.rpm glibc-langpack-lg-2.28-151.el8.x86_64.rpm glibc-langpack-li-2.28-151.el8.x86_64.rpm glibc-langpack-lij-2.28-151.el8.x86_64.rpm glibc-langpack-ln-2.28-151.el8.x86_64.rpm glibc-langpack-lo-2.28-151.el8.x86_64.rpm glibc-langpack-lt-2.28-151.el8.x86_64.rpm glibc-langpack-lv-2.28-151.el8.x86_64.rpm glibc-langpack-lzh-2.28-151.el8.x86_64.rpm glibc-langpack-mag-2.28-151.el8.x86_64.rpm glibc-langpack-mai-2.28-151.el8.x86_64.rpm glibc-langpack-mfe-2.28-151.el8.x86_64.rpm glibc-langpack-mg-2.28-151.el8.x86_64.rpm glibc-langpack-mhr-2.28-151.el8.x86_64.rpm glibc-langpack-mi-2.28-151.el8.x86_64.rpm glibc-langpack-miq-2.28-151.el8.x86_64.rpm glibc-langpack-mjw-2.28-151.el8.x86_64.rpm glibc-langpack-mk-2.28-151.el8.x86_64.rpm glibc-langpack-ml-2.28-151.el8.x86_64.rpm glibc-langpack-mn-2.28-151.el8.x86_64.rpm glibc-langpack-mni-2.28-151.el8.x86_64.rpm glibc-langpack-mr-2.28-151.el8.x86_64.rpm glibc-langpack-ms-2.28-151.el8.x86_64.rpm glibc-langpack-mt-2.28-151.el8.x86_64.rpm glibc-langpack-my-2.28-151.el8.x86_64.rpm glibc-langpack-nan-2.28-151.el8.x86_64.rpm glibc-langpack-nb-2.28-151.el8.x86_64.rpm glibc-langpack-nds-2.28-151.el8.x86_64.rpm glibc-langpack-ne-2.28-151.el8.x86_64.rpm glibc-langpack-nhn-2.28-151.el8.x86_64.rpm glibc-langpack-niu-2.28-151.el8.x86_64.rpm glibc-langpack-nl-2.28-151.el8.x86_64.rpm glibc-langpack-nn-2.28-151.el8.x86_64.rpm glibc-langpack-nr-2.28-151.el8.x86_64.rpm glibc-langpack-nso-2.28-151.el8.x86_64.rpm glibc-langpack-oc-2.28-151.el8.x86_64.rpm glibc-langpack-om-2.28-151.el8.x86_64.rpm glibc-langpack-or-2.28-151.el8.x86_64.rpm glibc-langpack-os-2.28-151.el8.x86_64.rpm glibc-langpack-pa-2.28-151.el8.x86_64.rpm glibc-langpack-pap-2.28-151.el8.x86_64.rpm glibc-langpack-pl-2.28-151.el8.x86_64.rpm glibc-langpack-ps-2.28-151.el8.x86_64.rpm glibc-langpack-pt-2.28-151.el8.x86_64.rpm glibc-langpack-quz-2.28-151.el8.x86_64.rpm glibc-langpack-raj-2.28-151.el8.x86_64.rpm glibc-langpack-ro-2.28-151.el8.x86_64.rpm glibc-langpack-ru-2.28-151.el8.x86_64.rpm glibc-langpack-rw-2.28-151.el8.x86_64.rpm glibc-langpack-sa-2.28-151.el8.x86_64.rpm glibc-langpack-sah-2.28-151.el8.x86_64.rpm glibc-langpack-sat-2.28-151.el8.x86_64.rpm glibc-langpack-sc-2.28-151.el8.x86_64.rpm glibc-langpack-sd-2.28-151.el8.x86_64.rpm glibc-langpack-se-2.28-151.el8.x86_64.rpm glibc-langpack-sgs-2.28-151.el8.x86_64.rpm glibc-langpack-shn-2.28-151.el8.x86_64.rpm glibc-langpack-shs-2.28-151.el8.x86_64.rpm glibc-langpack-si-2.28-151.el8.x86_64.rpm glibc-langpack-sid-2.28-151.el8.x86_64.rpm glibc-langpack-sk-2.28-151.el8.x86_64.rpm glibc-langpack-sl-2.28-151.el8.x86_64.rpm glibc-langpack-sm-2.28-151.el8.x86_64.rpm glibc-langpack-so-2.28-151.el8.x86_64.rpm glibc-langpack-sq-2.28-151.el8.x86_64.rpm glibc-langpack-sr-2.28-151.el8.x86_64.rpm glibc-langpack-ss-2.28-151.el8.x86_64.rpm glibc-langpack-st-2.28-151.el8.x86_64.rpm glibc-langpack-sv-2.28-151.el8.x86_64.rpm glibc-langpack-sw-2.28-151.el8.x86_64.rpm glibc-langpack-szl-2.28-151.el8.x86_64.rpm glibc-langpack-ta-2.28-151.el8.x86_64.rpm glibc-langpack-tcy-2.28-151.el8.x86_64.rpm glibc-langpack-te-2.28-151.el8.x86_64.rpm glibc-langpack-tg-2.28-151.el8.x86_64.rpm glibc-langpack-th-2.28-151.el8.x86_64.rpm glibc-langpack-the-2.28-151.el8.x86_64.rpm glibc-langpack-ti-2.28-151.el8.x86_64.rpm glibc-langpack-tig-2.28-151.el8.x86_64.rpm glibc-langpack-tk-2.28-151.el8.x86_64.rpm glibc-langpack-tl-2.28-151.el8.x86_64.rpm glibc-langpack-tn-2.28-151.el8.x86_64.rpm glibc-langpack-to-2.28-151.el8.x86_64.rpm glibc-langpack-tpi-2.28-151.el8.x86_64.rpm glibc-langpack-tr-2.28-151.el8.x86_64.rpm glibc-langpack-ts-2.28-151.el8.x86_64.rpm glibc-langpack-tt-2.28-151.el8.x86_64.rpm glibc-langpack-ug-2.28-151.el8.x86_64.rpm glibc-langpack-uk-2.28-151.el8.x86_64.rpm glibc-langpack-unm-2.28-151.el8.x86_64.rpm glibc-langpack-ur-2.28-151.el8.x86_64.rpm glibc-langpack-uz-2.28-151.el8.x86_64.rpm glibc-langpack-ve-2.28-151.el8.x86_64.rpm glibc-langpack-vi-2.28-151.el8.x86_64.rpm glibc-langpack-wa-2.28-151.el8.x86_64.rpm glibc-langpack-wae-2.28-151.el8.x86_64.rpm glibc-langpack-wal-2.28-151.el8.x86_64.rpm glibc-langpack-wo-2.28-151.el8.x86_64.rpm glibc-langpack-xh-2.28-151.el8.x86_64.rpm glibc-langpack-yi-2.28-151.el8.x86_64.rpm glibc-langpack-yo-2.28-151.el8.x86_64.rpm glibc-langpack-yue-2.28-151.el8.x86_64.rpm glibc-langpack-yuw-2.28-151.el8.x86_64.rpm glibc-langpack-zh-2.28-151.el8.x86_64.rpm glibc-langpack-zu-2.28-151.el8.x86_64.rpm glibc-locale-source-2.28-151.el8.x86_64.rpm glibc-minimal-langpack-2.28-151.el8.x86_64.rpm libnsl-2.28-151.el8.i686.rpm libnsl-2.28-151.el8.x86_64.rpm nscd-2.28-151.el8.x86_64.rpm nss_db-2.28-151.el8.i686.rpm nss_db-2.28-151.el8.x86_64.rpm
Red Hat CodeReady Linux Builder (v. 8):
aarch64: glibc-benchtests-2.28-151.el8.aarch64.rpm glibc-debuginfo-2.28-151.el8.aarch64.rpm glibc-nss-devel-2.28-151.el8.aarch64.rpm glibc-static-2.28-151.el8.aarch64.rpm nss_hesiod-2.28-151.el8.aarch64.rpm
ppc64le: glibc-benchtests-2.28-151.el8.ppc64le.rpm glibc-debuginfo-2.28-151.el8.ppc64le.rpm glibc-debuginfo-common-2.28-151.el8.ppc64le.rpm glibc-nss-devel-2.28-151.el8.ppc64le.rpm glibc-static-2.28-151.el8.ppc64le.rpm nss_hesiod-2.28-151.el8.ppc64le.rpm
s390x: glibc-benchtests-2.28-151.el8.s390x.rpm glibc-debuginfo-2.28-151.el8.s390x.rpm glibc-debuginfo-common-2.28-151.el8.s390x.rpm glibc-nss-devel-2.28-151.el8.s390x.rpm glibc-static-2.28-151.el8.s390x.rpm nss_hesiod-2.28-151.el8.s390x.rpm
x86_64: glibc-benchtests-2.28-151.el8.x86_64.rpm glibc-debuginfo-2.28-151.el8.i686.rpm glibc-debuginfo-2.28-151.el8.x86_64.rpm glibc-debuginfo-common-2.28-151.el8.i686.rpm glibc-debuginfo-common-2.28-151.el8.x86_64.rpm glibc-nss-devel-2.28-151.el8.i686.rpm glibc-nss-devel-2.28-151.el8.x86_64.rpm glibc-static-2.28-151.el8.i686.rpm glibc-static-2.28-151.el8.x86_64.rpm nss_hesiod-2.28-151.el8.i686.rpm nss_hesiod-2.28-151.el8.x86_64.rpm
These packages are GPG signed by Red Hat for security. Our key and details on how to verify the signature are available from https://access.redhat.com/security/team/key/
- References:
https://access.redhat.com/security/cve/CVE-2016-10228 https://access.redhat.com/security/cve/CVE-2019-9169 https://access.redhat.com/security/cve/CVE-2019-25013 https://access.redhat.com/security/cve/CVE-2020-27618 https://access.redhat.com/security/cve/CVE-2021-3326 https://access.redhat.com/security/updates/classification/#moderate https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/8.4_release_notes/
- Contact:
The Red Hat security contact is secalert@redhat.com. More contact details at https://access.redhat.com/security/team/contact/
Copyright 2021 Red Hat, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iQIVAwUBYKPuENzjgjWX9erEAQi9vw//WZ4SvQsaE50S6H2/awuIPpTwqS9G8F1e Rb3LxhoDtMidhwTtLX7GxvPUngmjG9gD9F2ySLYYltNYXGeI4RaRwwgaAJbJuaEG POBR+tUKvTr/2qgNOuvvTkI5VIVSuFHL4szD4DLpntnD4fBVWTrKrSy4ZBmuH8lD 65l2JvjTQgwxqFIIEbZz6quulCLYY7y080tLKJPCIqBTJWsS7VR3/4jo8YGwzls0 u7zMsDcAhx7Y5mFSjZEds+KyT0kYQUW8N7SioeEKwfz3jteEbx7I+vyQUOYy9FZn o13BjgNrfNktX6jV48d9Mj/t1+YGFYRu7GIuct9EjYLs4qE9LIKn8MCxVE3uwT+P o4BlYwuXKZ5xBHBwU5nIElfttpyBynX6JuDXI9uw4On2p2ZWp4sqOwxm2Hpg3mK0 Bl5QR3sf3xIfnK8ZqEfR98H4QlY9bAwnLup2SgAxCiEPxsXlxBLeLRbaDlWBrvL2 6KhUSLKCWNO3qAlDzVsqxbTXdbfVXkTut4bhdJz6tqfSD9fYpfqrMuSTQyKWMFm9 FJ/l7yctRxZKC4D5CMrc+YAe9R/LLzokU83R9NA4NoViASuVXkYP6sBli0U9A8aw FTGqEOMIdVrT7C1C4NHM7dZgnAvjL22CbavMzjdnAySMRQxl5Je+vuK6jiZqTFwQ ouzI0iwzGJs=R8FH -----END PGP SIGNATURE-----
-- RHSA-announce mailing list RHSA-announce@redhat.com https://listman.redhat.com/mailman/listinfo/rhsa-announce .
Bug Fix(es):
-
WMCO patch pub-key-hash annotation to Linux node (BZ#1945248)
-
LoadBalancer Service type with invalid external loadbalancer IP breaks the datapath (BZ#1952917)
-
Telemetry info not completely available to identify windows nodes (BZ#1955319)
-
WMCO incorrectly shows node as ready after a failed configuration (BZ#1956412)
-
kube-proxy service terminated unexpectedly after recreated LB service (BZ#1963263)
-
Solution:
For Windows Machine Config Operator upgrades, see the following documentation:
https://docs.openshift.com/container-platform/4.7/windows_containers/window s-node-upgrades.html
- Bugs fixed (https://bugzilla.redhat.com/):
1945248 - WMCO patch pub-key-hash annotation to Linux node 1946538 - CVE-2021-25736 kubernetes: LoadBalancer Service type don't create a HNS policy for empty or invalid external loadbalancer IP, what could lead to MITM 1952917 - LoadBalancer Service type with invalid external loadbalancer IP breaks the datapath 1955319 - Telemetry info not completely available to identify windows nodes 1956412 - WMCO incorrectly shows node as ready after a failed configuration 1963263 - kube-proxy service terminated unexpectedly after recreated LB service
- Bugs fixed (https://bugzilla.redhat.com/):
1937901 - CVE-2021-27918 golang: encoding/xml: infinite loop when using xml.NewTokenDecoder with a custom TokenReader 1958341 - CVE-2021-31525 golang: net/http: panic in ReadRequest and ReadResponse when reading a very large header 1965503 - CVE-2021-33196 golang: archive/zip: Malformed archive may cause panic or memory exhaustion 1971445 - Release of OpenShift Serverless Serving 1.16.0 1971448 - Release of OpenShift Serverless Eventing 1.16.0
- Description:
Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments.
For 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.
This advisory contains the container images for Red Hat OpenShift Container Platform 4.7.13. See the following advisory for the RPM packages for this release:
https://access.redhat.com/errata/RHSA-2021:2122
Space 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:
https://docs.openshift.com/container-platform/4.7/release_notes/ocp-4-7-rel ease-notes.html
This update fixes the following bug among others:
- Previously, resources for the ClusterOperator were being created early in the update process, which led to update failures when the ClusterOperator had no status condition while Operators were updating. This bug fix changes the timing of when these resources are created. As a result, updates can take place without errors. (BZ#1959238)
Security Fix(es):
- gogo/protobuf: plugin/unmarshal/unmarshal.go lacks certain index validation (CVE-2021-3121)
You may download the oc tool and use it to inspect release image metadata as follows:
(For x86_64 architecture)
$ oc adm release info quay.io/openshift-release-dev/ocp-release:4.7.13-x86_64
The image digest is sha256:783a2c963f35ccab38e82e6a8c7fa954c3a4551e07d2f43c06098828dd986ed4
(For s390x architecture)
$ oc adm release info quay.io/openshift-release-dev/ocp-release:4.7.13-s390x
The image digest is sha256:4cf44e68413acad063203e1ee8982fd01d8b9c1f8643a5b31cd7ff341b3199cd
(For ppc64le architecture)
$ oc adm release info quay.io/openshift-release-dev/ocp-release:4.7.13-ppc64le
The image digest is sha256:d47ce972f87f14f1f3c5d50428d2255d1256dae3f45c938ace88547478643e36
All 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
- Solution:
For OpenShift Container Platform 4.7 see the following documentation, which will be updated shortly for this release, for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update:
https://docs.openshift.com/container-platform/4.7/release_notes/ocp-4-7-rel ease-notes.html
Details on how to access this content are available at https://docs.openshift.com/container-platform/4.7/updating/updating-cluster - -cli.html
- Bugs fixed (https://bugzilla.redhat.com/):
1921650 - CVE-2021-3121 gogo/protobuf: plugin/unmarshal/unmarshal.go lacks certain index validation 1923268 - [Assisted-4.7] [Staging] Using two both spelling "canceled" "cancelled" 1947216 - [AWS] Missing iam:ListAttachedRolePolicies permission in permissions.go 1953963 - Enable/Disable host operations returns cluster resource with incomplete hosts list 1957749 - ovn-kubernetes pod should have CPU and memory requests set but not limits 1959238 - CVO creating cloud-controller-manager too early causing upgrade failures 1960103 - SR-IOV obliviously reboot the node 1961941 - Local Storage Operator using LocalVolume CR fails to create PV's when backend storage failure is simulated 1962302 - packageserver clusteroperator does not set reason or message for Available condition 1962312 - Deployment considered unhealthy despite being available and at latest generation 1962435 - Public DNS records were not deleted when destroying a cluster which is using byo private hosted zone 1963115 - Test verify /run filesystem contents failing
- Description:
Red Hat Advanced Cluster Management for Kubernetes 2.3.0 images
Red Hat Advanced Cluster Management for Kubernetes provides the capabilities to address common challenges that administrators and site reliability engineers face as they work across a range of public and private cloud environments. Clusters and applications are all visible and managed from a single console—with security policy built in. See the following Release Notes documentation, which will be updated shortly for this release, for additional details about this release:
https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_mana gement_for_kubernetes/2.3/html/release_notes/
Security:
-
fastify-reply-from: crafted URL allows prefix scape of the proxied backend service (CVE-2021-21321)
-
fastify-http-proxy: crafted URL allows prefix scape of the proxied backend service (CVE-2021-21322)
-
nodejs-netmask: improper input validation of octal input data (CVE-2021-28918)
-
redis: Integer overflow via STRALGO LCS command (CVE-2021-29477)
-
redis: Integer overflow via COPY command for large intsets (CVE-2021-29478)
-
nodejs-glob-parent: Regular expression denial of service (CVE-2020-28469)
-
nodejs-lodash: ReDoS via the toNumber, trim and trimEnd functions (CVE-2020-28500)
-
golang.org/x/text: Panic in language.ParseAcceptLanguage while parsing
-
-u- extension (CVE-2020-28851)
-
golang.org/x/text: Panic in language.ParseAcceptLanguage while processing bcp47 tag (CVE-2020-28852)
-
nodejs-ansi_up: XSS due to insufficient URL sanitization (CVE-2021-3377)
-
oras: zip-slip vulnerability via oras-pull (CVE-2021-21272)
-
redis: integer overflow when configurable limit for maximum supported bulk input size is too big on 32-bit platforms (CVE-2021-21309)
-
nodejs-lodash: command injection via template (CVE-2021-23337)
-
nodejs-hosted-git-info: Regular Expression denial of service via shortcutMatch in fromUrl() (CVE-2021-23362)
-
browserslist: parsing of invalid queries could result in Regular Expression Denial of Service (ReDoS) (CVE-2021-23364)
-
nodejs-postcss: Regular expression denial of service during source map parsing (CVE-2021-23368)
-
nodejs-handlebars: Remote code execution when compiling untrusted compile templates with strict:true option (CVE-2021-23369)
-
nodejs-postcss: ReDoS via getAnnotationURL() and loadAnnotation() in lib/previous-map.js (CVE-2021-23382)
-
nodejs-handlebars: Remote code execution when compiling untrusted compile templates with compat:true option (CVE-2021-23383)
-
openssl: integer overflow in CipherUpdate (CVE-2021-23840)
-
openssl: NULL pointer dereference in X509_issuer_and_serial_hash() (CVE-2021-23841)
-
nodejs-ua-parser-js: ReDoS via malicious User-Agent header (CVE-2021-27292)
-
grafana: snapshot feature allow an unauthenticated remote attacker to trigger a DoS via a remote API call (CVE-2021-27358)
-
nodejs-is-svg: ReDoS via malicious string (CVE-2021-28092)
-
nodejs-netmask: incorrectly parses an IP address that has octal integer with invalid character (CVE-2021-29418)
-
ulikunitz/xz: Infinite loop in readUvarint allows for denial of service (CVE-2021-29482)
-
normalize-url: ReDoS for data URLs (CVE-2021-33502)
-
nodejs-trim-newlines: ReDoS in .end() method (CVE-2021-33623)
-
nodejs-path-parse: ReDoS via splitDeviceRe, splitTailRe and splitPathRe (CVE-2021-23343)
-
html-parse-stringify: Regular Expression DoS (CVE-2021-23346)
-
openssl: incorrect SSLv2 rollback protection (CVE-2021-23839)
For more details about the security issues, including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE pages listed in the References section.
Bugs:
-
RFE Make the source code for the endpoint-metrics-operator public (BZ# 1913444)
-
cluster became offline after apiserver health check (BZ# 1942589)
-
Solution:
Before applying this update, make sure all previously released errata relevant to your system have been applied. Bugs fixed (https://bugzilla.redhat.com/):
1913333 - CVE-2020-28851 golang.org/x/text: Panic in language.ParseAcceptLanguage while parsing -u- extension 1913338 - CVE-2020-28852 golang.org/x/text: Panic in language.ParseAcceptLanguage while processing bcp47 tag 1913444 - RFE Make the source code for the endpoint-metrics-operator public 1921286 - CVE-2021-21272 oras: zip-slip vulnerability via oras-pull 1927520 - RHACM 2.3.0 images 1928937 - CVE-2021-23337 nodejs-lodash: command injection via template 1928954 - CVE-2020-28500 nodejs-lodash: ReDoS via the toNumber, trim and trimEnd functions 1930294 - CVE-2021-23839 openssl: incorrect SSLv2 rollback protection 1930310 - CVE-2021-23841 openssl: NULL pointer dereference in X509_issuer_and_serial_hash() 1930324 - CVE-2021-23840 openssl: integer overflow in CipherUpdate 1932634 - CVE-2021-21309 redis: integer overflow when configurable limit for maximum supported bulk input size is too big on 32-bit platforms 1936427 - CVE-2021-3377 nodejs-ansi_up: XSS due to insufficient URL sanitization 1939103 - CVE-2021-28092 nodejs-is-svg: ReDoS via malicious string 1940196 - View Resource YAML option shows 404 error when reviewing a Subscription for an application 1940613 - CVE-2021-27292 nodejs-ua-parser-js: ReDoS via malicious User-Agent header 1941024 - CVE-2021-27358 grafana: snapshot feature allow an unauthenticated remote attacker to trigger a DoS via a remote API call 1941675 - CVE-2021-23346 html-parse-stringify: Regular Expression DoS 1942178 - CVE-2021-21321 fastify-reply-from: crafted URL allows prefix scape of the proxied backend service 1942182 - CVE-2021-21322 fastify-http-proxy: crafted URL allows prefix scape of the proxied backend service 1942589 - cluster became offline after apiserver health check 1943208 - CVE-2021-23362 nodejs-hosted-git-info: Regular Expression denial of service via shortcutMatch in fromUrl() 1944822 - CVE-2021-29418 nodejs-netmask: incorrectly parses an IP address that has octal integer with invalid character 1944827 - CVE-2021-28918 nodejs-netmask: improper input validation of octal input data 1945459 - CVE-2020-28469 nodejs-glob-parent: Regular expression denial of service 1948761 - CVE-2021-23369 nodejs-handlebars: Remote code execution when compiling untrusted compile templates with strict:true option 1948763 - CVE-2021-23368 nodejs-postcss: Regular expression denial of service during source map parsing 1954150 - CVE-2021-23382 nodejs-postcss: ReDoS via getAnnotationURL() and loadAnnotation() in lib/previous-map.js 1954368 - CVE-2021-29482 ulikunitz/xz: Infinite loop in readUvarint allows for denial of service 1955619 - CVE-2021-23364 browserslist: parsing of invalid queries could result in Regular Expression Denial of Service (ReDoS) 1956688 - CVE-2021-23383 nodejs-handlebars: Remote code execution when compiling untrusted compile templates with compat:true option 1956818 - CVE-2021-23343 nodejs-path-parse: ReDoS via splitDeviceRe, splitTailRe and splitPathRe 1957410 - CVE-2021-29477 redis: Integer overflow via STRALGO LCS command 1957414 - CVE-2021-29478 redis: Integer overflow via COPY command for large intsets 1964461 - CVE-2021-33502 normalize-url: ReDoS for data URLs 1966615 - CVE-2021-33623 nodejs-trim-newlines: ReDoS in .end() method 1968122 - clusterdeployment fails because hiveadmission sc does not have correct permissions 1972703 - Subctl fails to join cluster, since it cannot auto-generate a valid cluster id 1983131 - Defragmenting an etcd member doesn't reduce the DB size (7.5GB) on a setup with ~1000 spoke clusters
- Description:
Service Telemetry Framework (STF) provides automated collection of measurements and data from remote clients, such as Red Hat OpenStack Platform or third-party nodes. Dockerfiles and scripts should be amended either to refer to this new image specifically, or to the latest image generally. Bugs fixed (https://bugzilla.redhat.com/):
2107342 - CVE-2022-30631 golang: compress/gzip: stack exhaustion in Reader.Read
5
Show details on source website{ "@context": { "@vocab": "https://www.variotdbs.pl/ref/VARIoTentry#", "affected_products": { "@id": "https://www.variotdbs.pl/ref/affected_products" }, "configurations": { "@id": "https://www.variotdbs.pl/ref/configurations" }, "credits": { "@id": "https://www.variotdbs.pl/ref/credits" }, "cvss": { "@id": "https://www.variotdbs.pl/ref/cvss/" }, "description": { "@id": "https://www.variotdbs.pl/ref/description/" }, "exploit_availability": { "@id": "https://www.variotdbs.pl/ref/exploit_availability/" }, "external_ids": { "@id": "https://www.variotdbs.pl/ref/external_ids/" }, "iot": { "@id": "https://www.variotdbs.pl/ref/iot/" }, "iot_taxonomy": { "@id": "https://www.variotdbs.pl/ref/iot_taxonomy/" }, "patch": { "@id": "https://www.variotdbs.pl/ref/patch/" }, "problemtype_data": { "@id": "https://www.variotdbs.pl/ref/problemtype_data/" }, "references": { "@id": "https://www.variotdbs.pl/ref/references/" }, "sources": { "@id": "https://www.variotdbs.pl/ref/sources/" }, "sources_release_date": { "@id": "https://www.variotdbs.pl/ref/sources_release_date/" }, "sources_update_date": { "@id": "https://www.variotdbs.pl/ref/sources_update_date/" }, "threat_type": { "@id": "https://www.variotdbs.pl/ref/threat_type/" }, "title": { "@id": "https://www.variotdbs.pl/ref/title/" }, "type": { "@id": "https://www.variotdbs.pl/ref/type/" } }, "@id": "https://www.variotdbs.pl/vuln/VAR-202101-0119", "affected_products": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/affected_products#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" }, "@id": "https://www.variotdbs.pl/ref/sources" } }, "data": [ { "model": "fedora", "scope": "eq", "trust": 1.0, "vendor": "fedoraproject", "version": "32" }, { "model": "ontap select deploy administration utility", "scope": "eq", "trust": 1.0, "vendor": "netapp", "version": null }, { "model": "fabric operating system", "scope": "eq", "trust": 1.0, "vendor": "broadcom", "version": null }, { "model": "glibc", "scope": "lte", "trust": 1.0, "vendor": "gnu", "version": "2.32" }, { "model": "a250", "scope": "eq", "trust": 1.0, "vendor": "netapp", "version": null }, { "model": "service processor", "scope": "eq", "trust": 1.0, "vendor": "netapp", "version": null }, { "model": "linux", "scope": "eq", "trust": 1.0, "vendor": "debian", "version": "10.0" }, { "model": "500f", "scope": "eq", "trust": 1.0, "vendor": "netapp", "version": null }, { "model": "fedora", "scope": "eq", "trust": 1.0, "vendor": "fedoraproject", "version": "33" }, { "model": "fas/aff baseboard management controller 500f", "scope": null, "trust": 0.8, "vendor": "netapp", "version": null }, { "model": "c library", "scope": null, "trust": 0.8, "vendor": "gnu", "version": null }, { "model": "fedora", "scope": null, "trust": 0.8, "vendor": "fedora", "version": null }, { "model": "service processor", "scope": null, "trust": 0.8, "vendor": "netapp", "version": null }, { "model": "fabric operating system", "scope": null, "trust": 0.8, "vendor": "broadcom", "version": null }, { "model": "ontap select deploy administration utility", "scope": null, "trust": 0.8, "vendor": "netapp", "version": null }, { "model": "fas/aff baseboard management controller a250", "scope": null, "trust": 0.8, "vendor": "netapp", "version": null } ], "sources": [ { "db": "JVNDB", "id": "JVNDB-2019-016179" }, { "db": "NVD", "id": "CVE-2019-25013" } ] }, "credits": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/credits#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "Red Hat", "sources": [ { "db": "PACKETSTORM", "id": "162634" }, { "db": "PACKETSTORM", "id": "162837" }, { "db": "PACKETSTORM", "id": "163257" }, { "db": "PACKETSTORM", "id": "163496" }, { "db": "PACKETSTORM", "id": "162877" }, { "db": "PACKETSTORM", "id": "163747" }, { "db": "PACKETSTORM", "id": "168011" }, { "db": "CNNVD", "id": "CNNVD-202101-048" } ], "trust": 1.3 }, "cve": "CVE-2019-25013", "cvss": { "@context": { "cvssV2": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/cvss/cvssV2#" }, "@id": "https://www.variotdbs.pl/ref/cvss/cvssV2" }, "cvssV3": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/cvss/cvssV3#" }, "@id": "https://www.variotdbs.pl/ref/cvss/cvssV3/" }, "severity": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/cvss/severity#" }, "@id": "https://www.variotdbs.pl/ref/cvss/severity" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" }, "@id": "https://www.variotdbs.pl/ref/sources" } }, "data": [ { "cvssV2": [ { "accessComplexity": "MEDIUM", "accessVector": "NETWORK", "authentication": "NONE", "author": "nvd@nist.gov", "availabilityImpact": "COMPLETE", "baseScore": 7.1, "confidentialityImpact": "NONE", "exploitabilityScore": 8.6, "id": "CVE-2019-25013", "impactScore": 6.9, "integrityImpact": "NONE", "severity": "HIGH", "trust": 1.9, "vectorString": "AV:N/AC:M/Au:N/C:N/I:N/A:C", "version": "2.0" } ], "cvssV3": [ { "attackComplexity": "HIGH", "attackVector": "NETWORK", "author": "nvd@nist.gov", "availabilityImpact": "HIGH", "baseScore": 5.9, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "exploitabilityScore": 2.2, "id": "CVE-2019-25013", "impactScore": 3.6, "integrityImpact": "NONE", "privilegesRequired": "NONE", "scope": "UNCHANGED", "trust": 1.0, "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H", "version": "3.1" }, { "attackComplexity": "High", "attackVector": "Network", "author": "NVD", "availabilityImpact": "High", "baseScore": 5.9, "baseSeverity": "Medium", "confidentialityImpact": "None", "exploitabilityScore": null, "id": "CVE-2019-25013", "impactScore": null, "integrityImpact": "None", "privilegesRequired": "None", "scope": "Unchanged", "trust": 0.8, "userInteraction": "None", "vectorString": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H", "version": "3.0" } ], "severity": [ { "author": "nvd@nist.gov", "id": "CVE-2019-25013", "trust": 1.0, "value": "MEDIUM" }, { "author": "NVD", "id": "CVE-2019-25013", "trust": 0.8, "value": "Medium" }, { "author": "CNNVD", "id": "CNNVD-202101-048", "trust": 0.6, "value": "MEDIUM" }, { "author": "VULMON", "id": "CVE-2019-25013", "trust": 0.1, "value": "HIGH" } ] } ], "sources": [ { "db": "VULMON", "id": "CVE-2019-25013" }, { "db": "JVNDB", "id": "JVNDB-2019-016179" }, { "db": "CNNVD", "id": "CNNVD-202101-048" }, { "db": "NVD", "id": "CVE-2019-25013" } ] }, "description": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/description#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "The iconv feature in the GNU C Library (aka glibc or libc6) through 2.32, when processing invalid multi-byte input sequences in the EUC-KR encoding, may have a buffer over-read. -----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\n==================================================================== \nRed Hat Security Advisory\n\nSynopsis: Moderate: glibc security, bug fix, and enhancement update\nAdvisory ID: RHSA-2021:1585-01\nProduct: Red Hat Enterprise Linux\nAdvisory URL: https://access.redhat.com/errata/RHSA-2021:1585\nIssue date: 2021-05-18\nCVE Names: CVE-2016-10228 CVE-2019-9169 CVE-2019-25013\n CVE-2020-27618 CVE-2021-3326\n====================================================================\n1. Summary:\n\nAn update for glibc is now available for Red Hat Enterprise Linux 8. \n\nRed Hat Product Security has rated this update as having a security impact\nof Moderate. A Common Vulnerability Scoring System (CVSS) base score, which\ngives a detailed severity rating, is available for each vulnerability from\nthe CVE link(s) in the References section. \n\n2. Relevant releases/architectures:\n\nRed Hat CodeReady Linux Builder (v. 8) - aarch64, ppc64le, s390x, x86_64\nRed Hat Enterprise Linux AppStream (v. 8) - aarch64, ppc64le, s390x, x86_64\nRed Hat Enterprise Linux BaseOS (v. 8) - aarch64, ppc64le, s390x, x86_64\n\n3. Description:\n\nThe glibc packages provide the standard C libraries (libc), POSIX thread\nlibraries (libpthread), standard math libraries (libm), and the name\nservice cache daemon (nscd) used by multiple programs on the system. \nWithout these libraries, the Linux system cannot function correctly. \n\nAdditional Changes:\n\nFor detailed information on changes in this release, see the Red Hat\nEnterprise Linux 8.4 Release Notes linked from the References section. \n\n4. Solution:\n\nFor details on how to apply this update, which includes the changes\ndescribed in this advisory, refer to:\n\nhttps://access.redhat.com/articles/11258\n\nFor the update to take effect, all services linked to the glibc library\nmust be restarted, or the system rebooted. \n\n5. Bugs fixed (https://bugzilla.redhat.com/):\n\n1428290 - CVE-2016-10228 glibc: iconv program can hang when invoked with the -c option\n1684057 - CVE-2019-9169 glibc: regular-expression match via proceed_next_node in posix/regexec.c leads to heap-based buffer over-read\n1704868 - CVE-2016-10228 glibc: iconv: Fix converter hangs and front end option parsing for //TRANSLIT and //IGNORE [rhel-8]\n1855790 - glibc: Update Intel CET support from upstream\n1856398 - glibc: Build with -moutline-atomics on aarch64\n1868106 - glibc: Transaction ID collisions cause slow DNS lookups in getaddrinfo\n1871385 - glibc: Improve auditing implementation (including DT_AUDIT, and DT_DEPAUDIT)\n1871387 - glibc: Improve IBM POWER9 architecture performance\n1871394 - glibc: Fix AVX2 off-by-one error in strncmp (swbz#25933)\n1871395 - glibc: Improve IBM Z (s390x) Performance\n1871396 - glibc: Improve use of static TLS surplus for optimizations. Package List:\n\nRed Hat Enterprise Linux AppStream (v. 8):\n\naarch64:\ncompat-libpthread-nonshared-2.28-151.el8.aarch64.rpm\nglibc-debuginfo-2.28-151.el8.aarch64.rpm\nglibc-utils-2.28-151.el8.aarch64.rpm\n\nppc64le:\ncompat-libpthread-nonshared-2.28-151.el8.ppc64le.rpm\nglibc-debuginfo-2.28-151.el8.ppc64le.rpm\nglibc-debuginfo-common-2.28-151.el8.ppc64le.rpm\nglibc-utils-2.28-151.el8.ppc64le.rpm\n\ns390x:\ncompat-libpthread-nonshared-2.28-151.el8.s390x.rpm\nglibc-debuginfo-2.28-151.el8.s390x.rpm\nglibc-debuginfo-common-2.28-151.el8.s390x.rpm\nglibc-utils-2.28-151.el8.s390x.rpm\n\nx86_64:\ncompat-libpthread-nonshared-2.28-151.el8.x86_64.rpm\nglibc-debuginfo-2.28-151.el8.x86_64.rpm\nglibc-debuginfo-common-2.28-151.el8.x86_64.rpm\nglibc-utils-2.28-151.el8.x86_64.rpm\n\nRed Hat Enterprise Linux BaseOS (v. 8):\n\nSource:\nglibc-2.28-151.el8.src.rpm\n\naarch64:\nglibc-2.28-151.el8.aarch64.rpm\nglibc-all-langpacks-2.28-151.el8.aarch64.rpm\nglibc-common-2.28-151.el8.aarch64.rpm\nglibc-debuginfo-2.28-151.el8.aarch64.rpm\nglibc-devel-2.28-151.el8.aarch64.rpm\nglibc-headers-2.28-151.el8.aarch64.rpm\nglibc-langpack-aa-2.28-151.el8.aarch64.rpm\nglibc-langpack-af-2.28-151.el8.aarch64.rpm\nglibc-langpack-agr-2.28-151.el8.aarch64.rpm\nglibc-langpack-ak-2.28-151.el8.aarch64.rpm\nglibc-langpack-am-2.28-151.el8.aarch64.rpm\nglibc-langpack-an-2.28-151.el8.aarch64.rpm\nglibc-langpack-anp-2.28-151.el8.aarch64.rpm\nglibc-langpack-ar-2.28-151.el8.aarch64.rpm\nglibc-langpack-as-2.28-151.el8.aarch64.rpm\nglibc-langpack-ast-2.28-151.el8.aarch64.rpm\nglibc-langpack-ayc-2.28-151.el8.aarch64.rpm\nglibc-langpack-az-2.28-151.el8.aarch64.rpm\nglibc-langpack-be-2.28-151.el8.aarch64.rpm\nglibc-langpack-bem-2.28-151.el8.aarch64.rpm\nglibc-langpack-ber-2.28-151.el8.aarch64.rpm\nglibc-langpack-bg-2.28-151.el8.aarch64.rpm\nglibc-langpack-bhb-2.28-151.el8.aarch64.rpm\nglibc-langpack-bho-2.28-151.el8.aarch64.rpm\nglibc-langpack-bi-2.28-151.el8.aarch64.rpm\nglibc-langpack-bn-2.28-151.el8.aarch64.rpm\nglibc-langpack-bo-2.28-151.el8.aarch64.rpm\nglibc-langpack-br-2.28-151.el8.aarch64.rpm\nglibc-langpack-brx-2.28-151.el8.aarch64.rpm\nglibc-langpack-bs-2.28-151.el8.aarch64.rpm\nglibc-langpack-byn-2.28-151.el8.aarch64.rpm\nglibc-langpack-ca-2.28-151.el8.aarch64.rpm\nglibc-langpack-ce-2.28-151.el8.aarch64.rpm\nglibc-langpack-chr-2.28-151.el8.aarch64.rpm\nglibc-langpack-cmn-2.28-151.el8.aarch64.rpm\nglibc-langpack-crh-2.28-151.el8.aarch64.rpm\nglibc-langpack-cs-2.28-151.el8.aarch64.rpm\nglibc-langpack-csb-2.28-151.el8.aarch64.rpm\nglibc-langpack-cv-2.28-151.el8.aarch64.rpm\nglibc-langpack-cy-2.28-151.el8.aarch64.rpm\nglibc-langpack-da-2.28-151.el8.aarch64.rpm\nglibc-langpack-de-2.28-151.el8.aarch64.rpm\nglibc-langpack-doi-2.28-151.el8.aarch64.rpm\nglibc-langpack-dsb-2.28-151.el8.aarch64.rpm\nglibc-langpack-dv-2.28-151.el8.aarch64.rpm\nglibc-langpack-dz-2.28-151.el8.aarch64.rpm\nglibc-langpack-el-2.28-151.el8.aarch64.rpm\nglibc-langpack-en-2.28-151.el8.aarch64.rpm\nglibc-langpack-eo-2.28-151.el8.aarch64.rpm\nglibc-langpack-es-2.28-151.el8.aarch64.rpm\nglibc-langpack-et-2.28-151.el8.aarch64.rpm\nglibc-langpack-eu-2.28-151.el8.aarch64.rpm\nglibc-langpack-fa-2.28-151.el8.aarch64.rpm\nglibc-langpack-ff-2.28-151.el8.aarch64.rpm\nglibc-langpack-fi-2.28-151.el8.aarch64.rpm\nglibc-langpack-fil-2.28-151.el8.aarch64.rpm\nglibc-langpack-fo-2.28-151.el8.aarch64.rpm\nglibc-langpack-fr-2.28-151.el8.aarch64.rpm\nglibc-langpack-fur-2.28-151.el8.aarch64.rpm\nglibc-langpack-fy-2.28-151.el8.aarch64.rpm\nglibc-langpack-ga-2.28-151.el8.aarch64.rpm\nglibc-langpack-gd-2.28-151.el8.aarch64.rpm\nglibc-langpack-gez-2.28-151.el8.aarch64.rpm\nglibc-langpack-gl-2.28-151.el8.aarch64.rpm\nglibc-langpack-gu-2.28-151.el8.aarch64.rpm\nglibc-langpack-gv-2.28-151.el8.aarch64.rpm\nglibc-langpack-ha-2.28-151.el8.aarch64.rpm\nglibc-langpack-hak-2.28-151.el8.aarch64.rpm\nglibc-langpack-he-2.28-151.el8.aarch64.rpm\nglibc-langpack-hi-2.28-151.el8.aarch64.rpm\nglibc-langpack-hif-2.28-151.el8.aarch64.rpm\nglibc-langpack-hne-2.28-151.el8.aarch64.rpm\nglibc-langpack-hr-2.28-151.el8.aarch64.rpm\nglibc-langpack-hsb-2.28-151.el8.aarch64.rpm\nglibc-langpack-ht-2.28-151.el8.aarch64.rpm\nglibc-langpack-hu-2.28-151.el8.aarch64.rpm\nglibc-langpack-hy-2.28-151.el8.aarch64.rpm\nglibc-langpack-ia-2.28-151.el8.aarch64.rpm\nglibc-langpack-id-2.28-151.el8.aarch64.rpm\nglibc-langpack-ig-2.28-151.el8.aarch64.rpm\nglibc-langpack-ik-2.28-151.el8.aarch64.rpm\nglibc-langpack-is-2.28-151.el8.aarch64.rpm\nglibc-langpack-it-2.28-151.el8.aarch64.rpm\nglibc-langpack-iu-2.28-151.el8.aarch64.rpm\nglibc-langpack-ja-2.28-151.el8.aarch64.rpm\nglibc-langpack-ka-2.28-151.el8.aarch64.rpm\nglibc-langpack-kab-2.28-151.el8.aarch64.rpm\nglibc-langpack-kk-2.28-151.el8.aarch64.rpm\nglibc-langpack-kl-2.28-151.el8.aarch64.rpm\nglibc-langpack-km-2.28-151.el8.aarch64.rpm\nglibc-langpack-kn-2.28-151.el8.aarch64.rpm\nglibc-langpack-ko-2.28-151.el8.aarch64.rpm\nglibc-langpack-kok-2.28-151.el8.aarch64.rpm\nglibc-langpack-ks-2.28-151.el8.aarch64.rpm\nglibc-langpack-ku-2.28-151.el8.aarch64.rpm\nglibc-langpack-kw-2.28-151.el8.aarch64.rpm\nglibc-langpack-ky-2.28-151.el8.aarch64.rpm\nglibc-langpack-lb-2.28-151.el8.aarch64.rpm\nglibc-langpack-lg-2.28-151.el8.aarch64.rpm\nglibc-langpack-li-2.28-151.el8.aarch64.rpm\nglibc-langpack-lij-2.28-151.el8.aarch64.rpm\nglibc-langpack-ln-2.28-151.el8.aarch64.rpm\nglibc-langpack-lo-2.28-151.el8.aarch64.rpm\nglibc-langpack-lt-2.28-151.el8.aarch64.rpm\nglibc-langpack-lv-2.28-151.el8.aarch64.rpm\nglibc-langpack-lzh-2.28-151.el8.aarch64.rpm\nglibc-langpack-mag-2.28-151.el8.aarch64.rpm\nglibc-langpack-mai-2.28-151.el8.aarch64.rpm\nglibc-langpack-mfe-2.28-151.el8.aarch64.rpm\nglibc-langpack-mg-2.28-151.el8.aarch64.rpm\nglibc-langpack-mhr-2.28-151.el8.aarch64.rpm\nglibc-langpack-mi-2.28-151.el8.aarch64.rpm\nglibc-langpack-miq-2.28-151.el8.aarch64.rpm\nglibc-langpack-mjw-2.28-151.el8.aarch64.rpm\nglibc-langpack-mk-2.28-151.el8.aarch64.rpm\nglibc-langpack-ml-2.28-151.el8.aarch64.rpm\nglibc-langpack-mn-2.28-151.el8.aarch64.rpm\nglibc-langpack-mni-2.28-151.el8.aarch64.rpm\nglibc-langpack-mr-2.28-151.el8.aarch64.rpm\nglibc-langpack-ms-2.28-151.el8.aarch64.rpm\nglibc-langpack-mt-2.28-151.el8.aarch64.rpm\nglibc-langpack-my-2.28-151.el8.aarch64.rpm\nglibc-langpack-nan-2.28-151.el8.aarch64.rpm\nglibc-langpack-nb-2.28-151.el8.aarch64.rpm\nglibc-langpack-nds-2.28-151.el8.aarch64.rpm\nglibc-langpack-ne-2.28-151.el8.aarch64.rpm\nglibc-langpack-nhn-2.28-151.el8.aarch64.rpm\nglibc-langpack-niu-2.28-151.el8.aarch64.rpm\nglibc-langpack-nl-2.28-151.el8.aarch64.rpm\nglibc-langpack-nn-2.28-151.el8.aarch64.rpm\nglibc-langpack-nr-2.28-151.el8.aarch64.rpm\nglibc-langpack-nso-2.28-151.el8.aarch64.rpm\nglibc-langpack-oc-2.28-151.el8.aarch64.rpm\nglibc-langpack-om-2.28-151.el8.aarch64.rpm\nglibc-langpack-or-2.28-151.el8.aarch64.rpm\nglibc-langpack-os-2.28-151.el8.aarch64.rpm\nglibc-langpack-pa-2.28-151.el8.aarch64.rpm\nglibc-langpack-pap-2.28-151.el8.aarch64.rpm\nglibc-langpack-pl-2.28-151.el8.aarch64.rpm\nglibc-langpack-ps-2.28-151.el8.aarch64.rpm\nglibc-langpack-pt-2.28-151.el8.aarch64.rpm\nglibc-langpack-quz-2.28-151.el8.aarch64.rpm\nglibc-langpack-raj-2.28-151.el8.aarch64.rpm\nglibc-langpack-ro-2.28-151.el8.aarch64.rpm\nglibc-langpack-ru-2.28-151.el8.aarch64.rpm\nglibc-langpack-rw-2.28-151.el8.aarch64.rpm\nglibc-langpack-sa-2.28-151.el8.aarch64.rpm\nglibc-langpack-sah-2.28-151.el8.aarch64.rpm\nglibc-langpack-sat-2.28-151.el8.aarch64.rpm\nglibc-langpack-sc-2.28-151.el8.aarch64.rpm\nglibc-langpack-sd-2.28-151.el8.aarch64.rpm\nglibc-langpack-se-2.28-151.el8.aarch64.rpm\nglibc-langpack-sgs-2.28-151.el8.aarch64.rpm\nglibc-langpack-shn-2.28-151.el8.aarch64.rpm\nglibc-langpack-shs-2.28-151.el8.aarch64.rpm\nglibc-langpack-si-2.28-151.el8.aarch64.rpm\nglibc-langpack-sid-2.28-151.el8.aarch64.rpm\nglibc-langpack-sk-2.28-151.el8.aarch64.rpm\nglibc-langpack-sl-2.28-151.el8.aarch64.rpm\nglibc-langpack-sm-2.28-151.el8.aarch64.rpm\nglibc-langpack-so-2.28-151.el8.aarch64.rpm\nglibc-langpack-sq-2.28-151.el8.aarch64.rpm\nglibc-langpack-sr-2.28-151.el8.aarch64.rpm\nglibc-langpack-ss-2.28-151.el8.aarch64.rpm\nglibc-langpack-st-2.28-151.el8.aarch64.rpm\nglibc-langpack-sv-2.28-151.el8.aarch64.rpm\nglibc-langpack-sw-2.28-151.el8.aarch64.rpm\nglibc-langpack-szl-2.28-151.el8.aarch64.rpm\nglibc-langpack-ta-2.28-151.el8.aarch64.rpm\nglibc-langpack-tcy-2.28-151.el8.aarch64.rpm\nglibc-langpack-te-2.28-151.el8.aarch64.rpm\nglibc-langpack-tg-2.28-151.el8.aarch64.rpm\nglibc-langpack-th-2.28-151.el8.aarch64.rpm\nglibc-langpack-the-2.28-151.el8.aarch64.rpm\nglibc-langpack-ti-2.28-151.el8.aarch64.rpm\nglibc-langpack-tig-2.28-151.el8.aarch64.rpm\nglibc-langpack-tk-2.28-151.el8.aarch64.rpm\nglibc-langpack-tl-2.28-151.el8.aarch64.rpm\nglibc-langpack-tn-2.28-151.el8.aarch64.rpm\nglibc-langpack-to-2.28-151.el8.aarch64.rpm\nglibc-langpack-tpi-2.28-151.el8.aarch64.rpm\nglibc-langpack-tr-2.28-151.el8.aarch64.rpm\nglibc-langpack-ts-2.28-151.el8.aarch64.rpm\nglibc-langpack-tt-2.28-151.el8.aarch64.rpm\nglibc-langpack-ug-2.28-151.el8.aarch64.rpm\nglibc-langpack-uk-2.28-151.el8.aarch64.rpm\nglibc-langpack-unm-2.28-151.el8.aarch64.rpm\nglibc-langpack-ur-2.28-151.el8.aarch64.rpm\nglibc-langpack-uz-2.28-151.el8.aarch64.rpm\nglibc-langpack-ve-2.28-151.el8.aarch64.rpm\nglibc-langpack-vi-2.28-151.el8.aarch64.rpm\nglibc-langpack-wa-2.28-151.el8.aarch64.rpm\nglibc-langpack-wae-2.28-151.el8.aarch64.rpm\nglibc-langpack-wal-2.28-151.el8.aarch64.rpm\nglibc-langpack-wo-2.28-151.el8.aarch64.rpm\nglibc-langpack-xh-2.28-151.el8.aarch64.rpm\nglibc-langpack-yi-2.28-151.el8.aarch64.rpm\nglibc-langpack-yo-2.28-151.el8.aarch64.rpm\nglibc-langpack-yue-2.28-151.el8.aarch64.rpm\nglibc-langpack-yuw-2.28-151.el8.aarch64.rpm\nglibc-langpack-zh-2.28-151.el8.aarch64.rpm\nglibc-langpack-zu-2.28-151.el8.aarch64.rpm\nglibc-locale-source-2.28-151.el8.aarch64.rpm\nglibc-minimal-langpack-2.28-151.el8.aarch64.rpm\nlibnsl-2.28-151.el8.aarch64.rpm\nnscd-2.28-151.el8.aarch64.rpm\nnss_db-2.28-151.el8.aarch64.rpm\n\nppc64le:\nglibc-2.28-151.el8.ppc64le.rpm\nglibc-all-langpacks-2.28-151.el8.ppc64le.rpm\nglibc-common-2.28-151.el8.ppc64le.rpm\nglibc-debuginfo-2.28-151.el8.ppc64le.rpm\nglibc-debuginfo-common-2.28-151.el8.ppc64le.rpm\nglibc-devel-2.28-151.el8.ppc64le.rpm\nglibc-headers-2.28-151.el8.ppc64le.rpm\nglibc-langpack-aa-2.28-151.el8.ppc64le.rpm\nglibc-langpack-af-2.28-151.el8.ppc64le.rpm\nglibc-langpack-agr-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ak-2.28-151.el8.ppc64le.rpm\nglibc-langpack-am-2.28-151.el8.ppc64le.rpm\nglibc-langpack-an-2.28-151.el8.ppc64le.rpm\nglibc-langpack-anp-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ar-2.28-151.el8.ppc64le.rpm\nglibc-langpack-as-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ast-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ayc-2.28-151.el8.ppc64le.rpm\nglibc-langpack-az-2.28-151.el8.ppc64le.rpm\nglibc-langpack-be-2.28-151.el8.ppc64le.rpm\nglibc-langpack-bem-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ber-2.28-151.el8.ppc64le.rpm\nglibc-langpack-bg-2.28-151.el8.ppc64le.rpm\nglibc-langpack-bhb-2.28-151.el8.ppc64le.rpm\nglibc-langpack-bho-2.28-151.el8.ppc64le.rpm\nglibc-langpack-bi-2.28-151.el8.ppc64le.rpm\nglibc-langpack-bn-2.28-151.el8.ppc64le.rpm\nglibc-langpack-bo-2.28-151.el8.ppc64le.rpm\nglibc-langpack-br-2.28-151.el8.ppc64le.rpm\nglibc-langpack-brx-2.28-151.el8.ppc64le.rpm\nglibc-langpack-bs-2.28-151.el8.ppc64le.rpm\nglibc-langpack-byn-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ca-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ce-2.28-151.el8.ppc64le.rpm\nglibc-langpack-chr-2.28-151.el8.ppc64le.rpm\nglibc-langpack-cmn-2.28-151.el8.ppc64le.rpm\nglibc-langpack-crh-2.28-151.el8.ppc64le.rpm\nglibc-langpack-cs-2.28-151.el8.ppc64le.rpm\nglibc-langpack-csb-2.28-151.el8.ppc64le.rpm\nglibc-langpack-cv-2.28-151.el8.ppc64le.rpm\nglibc-langpack-cy-2.28-151.el8.ppc64le.rpm\nglibc-langpack-da-2.28-151.el8.ppc64le.rpm\nglibc-langpack-de-2.28-151.el8.ppc64le.rpm\nglibc-langpack-doi-2.28-151.el8.ppc64le.rpm\nglibc-langpack-dsb-2.28-151.el8.ppc64le.rpm\nglibc-langpack-dv-2.28-151.el8.ppc64le.rpm\nglibc-langpack-dz-2.28-151.el8.ppc64le.rpm\nglibc-langpack-el-2.28-151.el8.ppc64le.rpm\nglibc-langpack-en-2.28-151.el8.ppc64le.rpm\nglibc-langpack-eo-2.28-151.el8.ppc64le.rpm\nglibc-langpack-es-2.28-151.el8.ppc64le.rpm\nglibc-langpack-et-2.28-151.el8.ppc64le.rpm\nglibc-langpack-eu-2.28-151.el8.ppc64le.rpm\nglibc-langpack-fa-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ff-2.28-151.el8.ppc64le.rpm\nglibc-langpack-fi-2.28-151.el8.ppc64le.rpm\nglibc-langpack-fil-2.28-151.el8.ppc64le.rpm\nglibc-langpack-fo-2.28-151.el8.ppc64le.rpm\nglibc-langpack-fr-2.28-151.el8.ppc64le.rpm\nglibc-langpack-fur-2.28-151.el8.ppc64le.rpm\nglibc-langpack-fy-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ga-2.28-151.el8.ppc64le.rpm\nglibc-langpack-gd-2.28-151.el8.ppc64le.rpm\nglibc-langpack-gez-2.28-151.el8.ppc64le.rpm\nglibc-langpack-gl-2.28-151.el8.ppc64le.rpm\nglibc-langpack-gu-2.28-151.el8.ppc64le.rpm\nglibc-langpack-gv-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ha-2.28-151.el8.ppc64le.rpm\nglibc-langpack-hak-2.28-151.el8.ppc64le.rpm\nglibc-langpack-he-2.28-151.el8.ppc64le.rpm\nglibc-langpack-hi-2.28-151.el8.ppc64le.rpm\nglibc-langpack-hif-2.28-151.el8.ppc64le.rpm\nglibc-langpack-hne-2.28-151.el8.ppc64le.rpm\nglibc-langpack-hr-2.28-151.el8.ppc64le.rpm\nglibc-langpack-hsb-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ht-2.28-151.el8.ppc64le.rpm\nglibc-langpack-hu-2.28-151.el8.ppc64le.rpm\nglibc-langpack-hy-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ia-2.28-151.el8.ppc64le.rpm\nglibc-langpack-id-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ig-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ik-2.28-151.el8.ppc64le.rpm\nglibc-langpack-is-2.28-151.el8.ppc64le.rpm\nglibc-langpack-it-2.28-151.el8.ppc64le.rpm\nglibc-langpack-iu-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ja-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ka-2.28-151.el8.ppc64le.rpm\nglibc-langpack-kab-2.28-151.el8.ppc64le.rpm\nglibc-langpack-kk-2.28-151.el8.ppc64le.rpm\nglibc-langpack-kl-2.28-151.el8.ppc64le.rpm\nglibc-langpack-km-2.28-151.el8.ppc64le.rpm\nglibc-langpack-kn-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ko-2.28-151.el8.ppc64le.rpm\nglibc-langpack-kok-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ks-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ku-2.28-151.el8.ppc64le.rpm\nglibc-langpack-kw-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ky-2.28-151.el8.ppc64le.rpm\nglibc-langpack-lb-2.28-151.el8.ppc64le.rpm\nglibc-langpack-lg-2.28-151.el8.ppc64le.rpm\nglibc-langpack-li-2.28-151.el8.ppc64le.rpm\nglibc-langpack-lij-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ln-2.28-151.el8.ppc64le.rpm\nglibc-langpack-lo-2.28-151.el8.ppc64le.rpm\nglibc-langpack-lt-2.28-151.el8.ppc64le.rpm\nglibc-langpack-lv-2.28-151.el8.ppc64le.rpm\nglibc-langpack-lzh-2.28-151.el8.ppc64le.rpm\nglibc-langpack-mag-2.28-151.el8.ppc64le.rpm\nglibc-langpack-mai-2.28-151.el8.ppc64le.rpm\nglibc-langpack-mfe-2.28-151.el8.ppc64le.rpm\nglibc-langpack-mg-2.28-151.el8.ppc64le.rpm\nglibc-langpack-mhr-2.28-151.el8.ppc64le.rpm\nglibc-langpack-mi-2.28-151.el8.ppc64le.rpm\nglibc-langpack-miq-2.28-151.el8.ppc64le.rpm\nglibc-langpack-mjw-2.28-151.el8.ppc64le.rpm\nglibc-langpack-mk-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ml-2.28-151.el8.ppc64le.rpm\nglibc-langpack-mn-2.28-151.el8.ppc64le.rpm\nglibc-langpack-mni-2.28-151.el8.ppc64le.rpm\nglibc-langpack-mr-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ms-2.28-151.el8.ppc64le.rpm\nglibc-langpack-mt-2.28-151.el8.ppc64le.rpm\nglibc-langpack-my-2.28-151.el8.ppc64le.rpm\nglibc-langpack-nan-2.28-151.el8.ppc64le.rpm\nglibc-langpack-nb-2.28-151.el8.ppc64le.rpm\nglibc-langpack-nds-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ne-2.28-151.el8.ppc64le.rpm\nglibc-langpack-nhn-2.28-151.el8.ppc64le.rpm\nglibc-langpack-niu-2.28-151.el8.ppc64le.rpm\nglibc-langpack-nl-2.28-151.el8.ppc64le.rpm\nglibc-langpack-nn-2.28-151.el8.ppc64le.rpm\nglibc-langpack-nr-2.28-151.el8.ppc64le.rpm\nglibc-langpack-nso-2.28-151.el8.ppc64le.rpm\nglibc-langpack-oc-2.28-151.el8.ppc64le.rpm\nglibc-langpack-om-2.28-151.el8.ppc64le.rpm\nglibc-langpack-or-2.28-151.el8.ppc64le.rpm\nglibc-langpack-os-2.28-151.el8.ppc64le.rpm\nglibc-langpack-pa-2.28-151.el8.ppc64le.rpm\nglibc-langpack-pap-2.28-151.el8.ppc64le.rpm\nglibc-langpack-pl-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ps-2.28-151.el8.ppc64le.rpm\nglibc-langpack-pt-2.28-151.el8.ppc64le.rpm\nglibc-langpack-quz-2.28-151.el8.ppc64le.rpm\nglibc-langpack-raj-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ro-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ru-2.28-151.el8.ppc64le.rpm\nglibc-langpack-rw-2.28-151.el8.ppc64le.rpm\nglibc-langpack-sa-2.28-151.el8.ppc64le.rpm\nglibc-langpack-sah-2.28-151.el8.ppc64le.rpm\nglibc-langpack-sat-2.28-151.el8.ppc64le.rpm\nglibc-langpack-sc-2.28-151.el8.ppc64le.rpm\nglibc-langpack-sd-2.28-151.el8.ppc64le.rpm\nglibc-langpack-se-2.28-151.el8.ppc64le.rpm\nglibc-langpack-sgs-2.28-151.el8.ppc64le.rpm\nglibc-langpack-shn-2.28-151.el8.ppc64le.rpm\nglibc-langpack-shs-2.28-151.el8.ppc64le.rpm\nglibc-langpack-si-2.28-151.el8.ppc64le.rpm\nglibc-langpack-sid-2.28-151.el8.ppc64le.rpm\nglibc-langpack-sk-2.28-151.el8.ppc64le.rpm\nglibc-langpack-sl-2.28-151.el8.ppc64le.rpm\nglibc-langpack-sm-2.28-151.el8.ppc64le.rpm\nglibc-langpack-so-2.28-151.el8.ppc64le.rpm\nglibc-langpack-sq-2.28-151.el8.ppc64le.rpm\nglibc-langpack-sr-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ss-2.28-151.el8.ppc64le.rpm\nglibc-langpack-st-2.28-151.el8.ppc64le.rpm\nglibc-langpack-sv-2.28-151.el8.ppc64le.rpm\nglibc-langpack-sw-2.28-151.el8.ppc64le.rpm\nglibc-langpack-szl-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ta-2.28-151.el8.ppc64le.rpm\nglibc-langpack-tcy-2.28-151.el8.ppc64le.rpm\nglibc-langpack-te-2.28-151.el8.ppc64le.rpm\nglibc-langpack-tg-2.28-151.el8.ppc64le.rpm\nglibc-langpack-th-2.28-151.el8.ppc64le.rpm\nglibc-langpack-the-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ti-2.28-151.el8.ppc64le.rpm\nglibc-langpack-tig-2.28-151.el8.ppc64le.rpm\nglibc-langpack-tk-2.28-151.el8.ppc64le.rpm\nglibc-langpack-tl-2.28-151.el8.ppc64le.rpm\nglibc-langpack-tn-2.28-151.el8.ppc64le.rpm\nglibc-langpack-to-2.28-151.el8.ppc64le.rpm\nglibc-langpack-tpi-2.28-151.el8.ppc64le.rpm\nglibc-langpack-tr-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ts-2.28-151.el8.ppc64le.rpm\nglibc-langpack-tt-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ug-2.28-151.el8.ppc64le.rpm\nglibc-langpack-uk-2.28-151.el8.ppc64le.rpm\nglibc-langpack-unm-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ur-2.28-151.el8.ppc64le.rpm\nglibc-langpack-uz-2.28-151.el8.ppc64le.rpm\nglibc-langpack-ve-2.28-151.el8.ppc64le.rpm\nglibc-langpack-vi-2.28-151.el8.ppc64le.rpm\nglibc-langpack-wa-2.28-151.el8.ppc64le.rpm\nglibc-langpack-wae-2.28-151.el8.ppc64le.rpm\nglibc-langpack-wal-2.28-151.el8.ppc64le.rpm\nglibc-langpack-wo-2.28-151.el8.ppc64le.rpm\nglibc-langpack-xh-2.28-151.el8.ppc64le.rpm\nglibc-langpack-yi-2.28-151.el8.ppc64le.rpm\nglibc-langpack-yo-2.28-151.el8.ppc64le.rpm\nglibc-langpack-yue-2.28-151.el8.ppc64le.rpm\nglibc-langpack-yuw-2.28-151.el8.ppc64le.rpm\nglibc-langpack-zh-2.28-151.el8.ppc64le.rpm\nglibc-langpack-zu-2.28-151.el8.ppc64le.rpm\nglibc-locale-source-2.28-151.el8.ppc64le.rpm\nglibc-minimal-langpack-2.28-151.el8.ppc64le.rpm\nlibnsl-2.28-151.el8.ppc64le.rpm\nnscd-2.28-151.el8.ppc64le.rpm\nnss_db-2.28-151.el8.ppc64le.rpm\n\ns390x:\nglibc-2.28-151.el8.s390x.rpm\nglibc-all-langpacks-2.28-151.el8.s390x.rpm\nglibc-common-2.28-151.el8.s390x.rpm\nglibc-debuginfo-2.28-151.el8.s390x.rpm\nglibc-debuginfo-common-2.28-151.el8.s390x.rpm\nglibc-devel-2.28-151.el8.s390x.rpm\nglibc-headers-2.28-151.el8.s390x.rpm\nglibc-langpack-aa-2.28-151.el8.s390x.rpm\nglibc-langpack-af-2.28-151.el8.s390x.rpm\nglibc-langpack-agr-2.28-151.el8.s390x.rpm\nglibc-langpack-ak-2.28-151.el8.s390x.rpm\nglibc-langpack-am-2.28-151.el8.s390x.rpm\nglibc-langpack-an-2.28-151.el8.s390x.rpm\nglibc-langpack-anp-2.28-151.el8.s390x.rpm\nglibc-langpack-ar-2.28-151.el8.s390x.rpm\nglibc-langpack-as-2.28-151.el8.s390x.rpm\nglibc-langpack-ast-2.28-151.el8.s390x.rpm\nglibc-langpack-ayc-2.28-151.el8.s390x.rpm\nglibc-langpack-az-2.28-151.el8.s390x.rpm\nglibc-langpack-be-2.28-151.el8.s390x.rpm\nglibc-langpack-bem-2.28-151.el8.s390x.rpm\nglibc-langpack-ber-2.28-151.el8.s390x.rpm\nglibc-langpack-bg-2.28-151.el8.s390x.rpm\nglibc-langpack-bhb-2.28-151.el8.s390x.rpm\nglibc-langpack-bho-2.28-151.el8.s390x.rpm\nglibc-langpack-bi-2.28-151.el8.s390x.rpm\nglibc-langpack-bn-2.28-151.el8.s390x.rpm\nglibc-langpack-bo-2.28-151.el8.s390x.rpm\nglibc-langpack-br-2.28-151.el8.s390x.rpm\nglibc-langpack-brx-2.28-151.el8.s390x.rpm\nglibc-langpack-bs-2.28-151.el8.s390x.rpm\nglibc-langpack-byn-2.28-151.el8.s390x.rpm\nglibc-langpack-ca-2.28-151.el8.s390x.rpm\nglibc-langpack-ce-2.28-151.el8.s390x.rpm\nglibc-langpack-chr-2.28-151.el8.s390x.rpm\nglibc-langpack-cmn-2.28-151.el8.s390x.rpm\nglibc-langpack-crh-2.28-151.el8.s390x.rpm\nglibc-langpack-cs-2.28-151.el8.s390x.rpm\nglibc-langpack-csb-2.28-151.el8.s390x.rpm\nglibc-langpack-cv-2.28-151.el8.s390x.rpm\nglibc-langpack-cy-2.28-151.el8.s390x.rpm\nglibc-langpack-da-2.28-151.el8.s390x.rpm\nglibc-langpack-de-2.28-151.el8.s390x.rpm\nglibc-langpack-doi-2.28-151.el8.s390x.rpm\nglibc-langpack-dsb-2.28-151.el8.s390x.rpm\nglibc-langpack-dv-2.28-151.el8.s390x.rpm\nglibc-langpack-dz-2.28-151.el8.s390x.rpm\nglibc-langpack-el-2.28-151.el8.s390x.rpm\nglibc-langpack-en-2.28-151.el8.s390x.rpm\nglibc-langpack-eo-2.28-151.el8.s390x.rpm\nglibc-langpack-es-2.28-151.el8.s390x.rpm\nglibc-langpack-et-2.28-151.el8.s390x.rpm\nglibc-langpack-eu-2.28-151.el8.s390x.rpm\nglibc-langpack-fa-2.28-151.el8.s390x.rpm\nglibc-langpack-ff-2.28-151.el8.s390x.rpm\nglibc-langpack-fi-2.28-151.el8.s390x.rpm\nglibc-langpack-fil-2.28-151.el8.s390x.rpm\nglibc-langpack-fo-2.28-151.el8.s390x.rpm\nglibc-langpack-fr-2.28-151.el8.s390x.rpm\nglibc-langpack-fur-2.28-151.el8.s390x.rpm\nglibc-langpack-fy-2.28-151.el8.s390x.rpm\nglibc-langpack-ga-2.28-151.el8.s390x.rpm\nglibc-langpack-gd-2.28-151.el8.s390x.rpm\nglibc-langpack-gez-2.28-151.el8.s390x.rpm\nglibc-langpack-gl-2.28-151.el8.s390x.rpm\nglibc-langpack-gu-2.28-151.el8.s390x.rpm\nglibc-langpack-gv-2.28-151.el8.s390x.rpm\nglibc-langpack-ha-2.28-151.el8.s390x.rpm\nglibc-langpack-hak-2.28-151.el8.s390x.rpm\nglibc-langpack-he-2.28-151.el8.s390x.rpm\nglibc-langpack-hi-2.28-151.el8.s390x.rpm\nglibc-langpack-hif-2.28-151.el8.s390x.rpm\nglibc-langpack-hne-2.28-151.el8.s390x.rpm\nglibc-langpack-hr-2.28-151.el8.s390x.rpm\nglibc-langpack-hsb-2.28-151.el8.s390x.rpm\nglibc-langpack-ht-2.28-151.el8.s390x.rpm\nglibc-langpack-hu-2.28-151.el8.s390x.rpm\nglibc-langpack-hy-2.28-151.el8.s390x.rpm\nglibc-langpack-ia-2.28-151.el8.s390x.rpm\nglibc-langpack-id-2.28-151.el8.s390x.rpm\nglibc-langpack-ig-2.28-151.el8.s390x.rpm\nglibc-langpack-ik-2.28-151.el8.s390x.rpm\nglibc-langpack-is-2.28-151.el8.s390x.rpm\nglibc-langpack-it-2.28-151.el8.s390x.rpm\nglibc-langpack-iu-2.28-151.el8.s390x.rpm\nglibc-langpack-ja-2.28-151.el8.s390x.rpm\nglibc-langpack-ka-2.28-151.el8.s390x.rpm\nglibc-langpack-kab-2.28-151.el8.s390x.rpm\nglibc-langpack-kk-2.28-151.el8.s390x.rpm\nglibc-langpack-kl-2.28-151.el8.s390x.rpm\nglibc-langpack-km-2.28-151.el8.s390x.rpm\nglibc-langpack-kn-2.28-151.el8.s390x.rpm\nglibc-langpack-ko-2.28-151.el8.s390x.rpm\nglibc-langpack-kok-2.28-151.el8.s390x.rpm\nglibc-langpack-ks-2.28-151.el8.s390x.rpm\nglibc-langpack-ku-2.28-151.el8.s390x.rpm\nglibc-langpack-kw-2.28-151.el8.s390x.rpm\nglibc-langpack-ky-2.28-151.el8.s390x.rpm\nglibc-langpack-lb-2.28-151.el8.s390x.rpm\nglibc-langpack-lg-2.28-151.el8.s390x.rpm\nglibc-langpack-li-2.28-151.el8.s390x.rpm\nglibc-langpack-lij-2.28-151.el8.s390x.rpm\nglibc-langpack-ln-2.28-151.el8.s390x.rpm\nglibc-langpack-lo-2.28-151.el8.s390x.rpm\nglibc-langpack-lt-2.28-151.el8.s390x.rpm\nglibc-langpack-lv-2.28-151.el8.s390x.rpm\nglibc-langpack-lzh-2.28-151.el8.s390x.rpm\nglibc-langpack-mag-2.28-151.el8.s390x.rpm\nglibc-langpack-mai-2.28-151.el8.s390x.rpm\nglibc-langpack-mfe-2.28-151.el8.s390x.rpm\nglibc-langpack-mg-2.28-151.el8.s390x.rpm\nglibc-langpack-mhr-2.28-151.el8.s390x.rpm\nglibc-langpack-mi-2.28-151.el8.s390x.rpm\nglibc-langpack-miq-2.28-151.el8.s390x.rpm\nglibc-langpack-mjw-2.28-151.el8.s390x.rpm\nglibc-langpack-mk-2.28-151.el8.s390x.rpm\nglibc-langpack-ml-2.28-151.el8.s390x.rpm\nglibc-langpack-mn-2.28-151.el8.s390x.rpm\nglibc-langpack-mni-2.28-151.el8.s390x.rpm\nglibc-langpack-mr-2.28-151.el8.s390x.rpm\nglibc-langpack-ms-2.28-151.el8.s390x.rpm\nglibc-langpack-mt-2.28-151.el8.s390x.rpm\nglibc-langpack-my-2.28-151.el8.s390x.rpm\nglibc-langpack-nan-2.28-151.el8.s390x.rpm\nglibc-langpack-nb-2.28-151.el8.s390x.rpm\nglibc-langpack-nds-2.28-151.el8.s390x.rpm\nglibc-langpack-ne-2.28-151.el8.s390x.rpm\nglibc-langpack-nhn-2.28-151.el8.s390x.rpm\nglibc-langpack-niu-2.28-151.el8.s390x.rpm\nglibc-langpack-nl-2.28-151.el8.s390x.rpm\nglibc-langpack-nn-2.28-151.el8.s390x.rpm\nglibc-langpack-nr-2.28-151.el8.s390x.rpm\nglibc-langpack-nso-2.28-151.el8.s390x.rpm\nglibc-langpack-oc-2.28-151.el8.s390x.rpm\nglibc-langpack-om-2.28-151.el8.s390x.rpm\nglibc-langpack-or-2.28-151.el8.s390x.rpm\nglibc-langpack-os-2.28-151.el8.s390x.rpm\nglibc-langpack-pa-2.28-151.el8.s390x.rpm\nglibc-langpack-pap-2.28-151.el8.s390x.rpm\nglibc-langpack-pl-2.28-151.el8.s390x.rpm\nglibc-langpack-ps-2.28-151.el8.s390x.rpm\nglibc-langpack-pt-2.28-151.el8.s390x.rpm\nglibc-langpack-quz-2.28-151.el8.s390x.rpm\nglibc-langpack-raj-2.28-151.el8.s390x.rpm\nglibc-langpack-ro-2.28-151.el8.s390x.rpm\nglibc-langpack-ru-2.28-151.el8.s390x.rpm\nglibc-langpack-rw-2.28-151.el8.s390x.rpm\nglibc-langpack-sa-2.28-151.el8.s390x.rpm\nglibc-langpack-sah-2.28-151.el8.s390x.rpm\nglibc-langpack-sat-2.28-151.el8.s390x.rpm\nglibc-langpack-sc-2.28-151.el8.s390x.rpm\nglibc-langpack-sd-2.28-151.el8.s390x.rpm\nglibc-langpack-se-2.28-151.el8.s390x.rpm\nglibc-langpack-sgs-2.28-151.el8.s390x.rpm\nglibc-langpack-shn-2.28-151.el8.s390x.rpm\nglibc-langpack-shs-2.28-151.el8.s390x.rpm\nglibc-langpack-si-2.28-151.el8.s390x.rpm\nglibc-langpack-sid-2.28-151.el8.s390x.rpm\nglibc-langpack-sk-2.28-151.el8.s390x.rpm\nglibc-langpack-sl-2.28-151.el8.s390x.rpm\nglibc-langpack-sm-2.28-151.el8.s390x.rpm\nglibc-langpack-so-2.28-151.el8.s390x.rpm\nglibc-langpack-sq-2.28-151.el8.s390x.rpm\nglibc-langpack-sr-2.28-151.el8.s390x.rpm\nglibc-langpack-ss-2.28-151.el8.s390x.rpm\nglibc-langpack-st-2.28-151.el8.s390x.rpm\nglibc-langpack-sv-2.28-151.el8.s390x.rpm\nglibc-langpack-sw-2.28-151.el8.s390x.rpm\nglibc-langpack-szl-2.28-151.el8.s390x.rpm\nglibc-langpack-ta-2.28-151.el8.s390x.rpm\nglibc-langpack-tcy-2.28-151.el8.s390x.rpm\nglibc-langpack-te-2.28-151.el8.s390x.rpm\nglibc-langpack-tg-2.28-151.el8.s390x.rpm\nglibc-langpack-th-2.28-151.el8.s390x.rpm\nglibc-langpack-the-2.28-151.el8.s390x.rpm\nglibc-langpack-ti-2.28-151.el8.s390x.rpm\nglibc-langpack-tig-2.28-151.el8.s390x.rpm\nglibc-langpack-tk-2.28-151.el8.s390x.rpm\nglibc-langpack-tl-2.28-151.el8.s390x.rpm\nglibc-langpack-tn-2.28-151.el8.s390x.rpm\nglibc-langpack-to-2.28-151.el8.s390x.rpm\nglibc-langpack-tpi-2.28-151.el8.s390x.rpm\nglibc-langpack-tr-2.28-151.el8.s390x.rpm\nglibc-langpack-ts-2.28-151.el8.s390x.rpm\nglibc-langpack-tt-2.28-151.el8.s390x.rpm\nglibc-langpack-ug-2.28-151.el8.s390x.rpm\nglibc-langpack-uk-2.28-151.el8.s390x.rpm\nglibc-langpack-unm-2.28-151.el8.s390x.rpm\nglibc-langpack-ur-2.28-151.el8.s390x.rpm\nglibc-langpack-uz-2.28-151.el8.s390x.rpm\nglibc-langpack-ve-2.28-151.el8.s390x.rpm\nglibc-langpack-vi-2.28-151.el8.s390x.rpm\nglibc-langpack-wa-2.28-151.el8.s390x.rpm\nglibc-langpack-wae-2.28-151.el8.s390x.rpm\nglibc-langpack-wal-2.28-151.el8.s390x.rpm\nglibc-langpack-wo-2.28-151.el8.s390x.rpm\nglibc-langpack-xh-2.28-151.el8.s390x.rpm\nglibc-langpack-yi-2.28-151.el8.s390x.rpm\nglibc-langpack-yo-2.28-151.el8.s390x.rpm\nglibc-langpack-yue-2.28-151.el8.s390x.rpm\nglibc-langpack-yuw-2.28-151.el8.s390x.rpm\nglibc-langpack-zh-2.28-151.el8.s390x.rpm\nglibc-langpack-zu-2.28-151.el8.s390x.rpm\nglibc-locale-source-2.28-151.el8.s390x.rpm\nglibc-minimal-langpack-2.28-151.el8.s390x.rpm\nlibnsl-2.28-151.el8.s390x.rpm\nnscd-2.28-151.el8.s390x.rpm\nnss_db-2.28-151.el8.s390x.rpm\n\nx86_64:\nglibc-2.28-151.el8.i686.rpm\nglibc-2.28-151.el8.x86_64.rpm\nglibc-all-langpacks-2.28-151.el8.x86_64.rpm\nglibc-common-2.28-151.el8.x86_64.rpm\nglibc-debuginfo-2.28-151.el8.i686.rpm\nglibc-debuginfo-2.28-151.el8.x86_64.rpm\nglibc-debuginfo-common-2.28-151.el8.i686.rpm\nglibc-debuginfo-common-2.28-151.el8.x86_64.rpm\nglibc-devel-2.28-151.el8.i686.rpm\nglibc-devel-2.28-151.el8.x86_64.rpm\nglibc-headers-2.28-151.el8.i686.rpm\nglibc-headers-2.28-151.el8.x86_64.rpm\nglibc-langpack-aa-2.28-151.el8.x86_64.rpm\nglibc-langpack-af-2.28-151.el8.x86_64.rpm\nglibc-langpack-agr-2.28-151.el8.x86_64.rpm\nglibc-langpack-ak-2.28-151.el8.x86_64.rpm\nglibc-langpack-am-2.28-151.el8.x86_64.rpm\nglibc-langpack-an-2.28-151.el8.x86_64.rpm\nglibc-langpack-anp-2.28-151.el8.x86_64.rpm\nglibc-langpack-ar-2.28-151.el8.x86_64.rpm\nglibc-langpack-as-2.28-151.el8.x86_64.rpm\nglibc-langpack-ast-2.28-151.el8.x86_64.rpm\nglibc-langpack-ayc-2.28-151.el8.x86_64.rpm\nglibc-langpack-az-2.28-151.el8.x86_64.rpm\nglibc-langpack-be-2.28-151.el8.x86_64.rpm\nglibc-langpack-bem-2.28-151.el8.x86_64.rpm\nglibc-langpack-ber-2.28-151.el8.x86_64.rpm\nglibc-langpack-bg-2.28-151.el8.x86_64.rpm\nglibc-langpack-bhb-2.28-151.el8.x86_64.rpm\nglibc-langpack-bho-2.28-151.el8.x86_64.rpm\nglibc-langpack-bi-2.28-151.el8.x86_64.rpm\nglibc-langpack-bn-2.28-151.el8.x86_64.rpm\nglibc-langpack-bo-2.28-151.el8.x86_64.rpm\nglibc-langpack-br-2.28-151.el8.x86_64.rpm\nglibc-langpack-brx-2.28-151.el8.x86_64.rpm\nglibc-langpack-bs-2.28-151.el8.x86_64.rpm\nglibc-langpack-byn-2.28-151.el8.x86_64.rpm\nglibc-langpack-ca-2.28-151.el8.x86_64.rpm\nglibc-langpack-ce-2.28-151.el8.x86_64.rpm\nglibc-langpack-chr-2.28-151.el8.x86_64.rpm\nglibc-langpack-cmn-2.28-151.el8.x86_64.rpm\nglibc-langpack-crh-2.28-151.el8.x86_64.rpm\nglibc-langpack-cs-2.28-151.el8.x86_64.rpm\nglibc-langpack-csb-2.28-151.el8.x86_64.rpm\nglibc-langpack-cv-2.28-151.el8.x86_64.rpm\nglibc-langpack-cy-2.28-151.el8.x86_64.rpm\nglibc-langpack-da-2.28-151.el8.x86_64.rpm\nglibc-langpack-de-2.28-151.el8.x86_64.rpm\nglibc-langpack-doi-2.28-151.el8.x86_64.rpm\nglibc-langpack-dsb-2.28-151.el8.x86_64.rpm\nglibc-langpack-dv-2.28-151.el8.x86_64.rpm\nglibc-langpack-dz-2.28-151.el8.x86_64.rpm\nglibc-langpack-el-2.28-151.el8.x86_64.rpm\nglibc-langpack-en-2.28-151.el8.x86_64.rpm\nglibc-langpack-eo-2.28-151.el8.x86_64.rpm\nglibc-langpack-es-2.28-151.el8.x86_64.rpm\nglibc-langpack-et-2.28-151.el8.x86_64.rpm\nglibc-langpack-eu-2.28-151.el8.x86_64.rpm\nglibc-langpack-fa-2.28-151.el8.x86_64.rpm\nglibc-langpack-ff-2.28-151.el8.x86_64.rpm\nglibc-langpack-fi-2.28-151.el8.x86_64.rpm\nglibc-langpack-fil-2.28-151.el8.x86_64.rpm\nglibc-langpack-fo-2.28-151.el8.x86_64.rpm\nglibc-langpack-fr-2.28-151.el8.x86_64.rpm\nglibc-langpack-fur-2.28-151.el8.x86_64.rpm\nglibc-langpack-fy-2.28-151.el8.x86_64.rpm\nglibc-langpack-ga-2.28-151.el8.x86_64.rpm\nglibc-langpack-gd-2.28-151.el8.x86_64.rpm\nglibc-langpack-gez-2.28-151.el8.x86_64.rpm\nglibc-langpack-gl-2.28-151.el8.x86_64.rpm\nglibc-langpack-gu-2.28-151.el8.x86_64.rpm\nglibc-langpack-gv-2.28-151.el8.x86_64.rpm\nglibc-langpack-ha-2.28-151.el8.x86_64.rpm\nglibc-langpack-hak-2.28-151.el8.x86_64.rpm\nglibc-langpack-he-2.28-151.el8.x86_64.rpm\nglibc-langpack-hi-2.28-151.el8.x86_64.rpm\nglibc-langpack-hif-2.28-151.el8.x86_64.rpm\nglibc-langpack-hne-2.28-151.el8.x86_64.rpm\nglibc-langpack-hr-2.28-151.el8.x86_64.rpm\nglibc-langpack-hsb-2.28-151.el8.x86_64.rpm\nglibc-langpack-ht-2.28-151.el8.x86_64.rpm\nglibc-langpack-hu-2.28-151.el8.x86_64.rpm\nglibc-langpack-hy-2.28-151.el8.x86_64.rpm\nglibc-langpack-ia-2.28-151.el8.x86_64.rpm\nglibc-langpack-id-2.28-151.el8.x86_64.rpm\nglibc-langpack-ig-2.28-151.el8.x86_64.rpm\nglibc-langpack-ik-2.28-151.el8.x86_64.rpm\nglibc-langpack-is-2.28-151.el8.x86_64.rpm\nglibc-langpack-it-2.28-151.el8.x86_64.rpm\nglibc-langpack-iu-2.28-151.el8.x86_64.rpm\nglibc-langpack-ja-2.28-151.el8.x86_64.rpm\nglibc-langpack-ka-2.28-151.el8.x86_64.rpm\nglibc-langpack-kab-2.28-151.el8.x86_64.rpm\nglibc-langpack-kk-2.28-151.el8.x86_64.rpm\nglibc-langpack-kl-2.28-151.el8.x86_64.rpm\nglibc-langpack-km-2.28-151.el8.x86_64.rpm\nglibc-langpack-kn-2.28-151.el8.x86_64.rpm\nglibc-langpack-ko-2.28-151.el8.x86_64.rpm\nglibc-langpack-kok-2.28-151.el8.x86_64.rpm\nglibc-langpack-ks-2.28-151.el8.x86_64.rpm\nglibc-langpack-ku-2.28-151.el8.x86_64.rpm\nglibc-langpack-kw-2.28-151.el8.x86_64.rpm\nglibc-langpack-ky-2.28-151.el8.x86_64.rpm\nglibc-langpack-lb-2.28-151.el8.x86_64.rpm\nglibc-langpack-lg-2.28-151.el8.x86_64.rpm\nglibc-langpack-li-2.28-151.el8.x86_64.rpm\nglibc-langpack-lij-2.28-151.el8.x86_64.rpm\nglibc-langpack-ln-2.28-151.el8.x86_64.rpm\nglibc-langpack-lo-2.28-151.el8.x86_64.rpm\nglibc-langpack-lt-2.28-151.el8.x86_64.rpm\nglibc-langpack-lv-2.28-151.el8.x86_64.rpm\nglibc-langpack-lzh-2.28-151.el8.x86_64.rpm\nglibc-langpack-mag-2.28-151.el8.x86_64.rpm\nglibc-langpack-mai-2.28-151.el8.x86_64.rpm\nglibc-langpack-mfe-2.28-151.el8.x86_64.rpm\nglibc-langpack-mg-2.28-151.el8.x86_64.rpm\nglibc-langpack-mhr-2.28-151.el8.x86_64.rpm\nglibc-langpack-mi-2.28-151.el8.x86_64.rpm\nglibc-langpack-miq-2.28-151.el8.x86_64.rpm\nglibc-langpack-mjw-2.28-151.el8.x86_64.rpm\nglibc-langpack-mk-2.28-151.el8.x86_64.rpm\nglibc-langpack-ml-2.28-151.el8.x86_64.rpm\nglibc-langpack-mn-2.28-151.el8.x86_64.rpm\nglibc-langpack-mni-2.28-151.el8.x86_64.rpm\nglibc-langpack-mr-2.28-151.el8.x86_64.rpm\nglibc-langpack-ms-2.28-151.el8.x86_64.rpm\nglibc-langpack-mt-2.28-151.el8.x86_64.rpm\nglibc-langpack-my-2.28-151.el8.x86_64.rpm\nglibc-langpack-nan-2.28-151.el8.x86_64.rpm\nglibc-langpack-nb-2.28-151.el8.x86_64.rpm\nglibc-langpack-nds-2.28-151.el8.x86_64.rpm\nglibc-langpack-ne-2.28-151.el8.x86_64.rpm\nglibc-langpack-nhn-2.28-151.el8.x86_64.rpm\nglibc-langpack-niu-2.28-151.el8.x86_64.rpm\nglibc-langpack-nl-2.28-151.el8.x86_64.rpm\nglibc-langpack-nn-2.28-151.el8.x86_64.rpm\nglibc-langpack-nr-2.28-151.el8.x86_64.rpm\nglibc-langpack-nso-2.28-151.el8.x86_64.rpm\nglibc-langpack-oc-2.28-151.el8.x86_64.rpm\nglibc-langpack-om-2.28-151.el8.x86_64.rpm\nglibc-langpack-or-2.28-151.el8.x86_64.rpm\nglibc-langpack-os-2.28-151.el8.x86_64.rpm\nglibc-langpack-pa-2.28-151.el8.x86_64.rpm\nglibc-langpack-pap-2.28-151.el8.x86_64.rpm\nglibc-langpack-pl-2.28-151.el8.x86_64.rpm\nglibc-langpack-ps-2.28-151.el8.x86_64.rpm\nglibc-langpack-pt-2.28-151.el8.x86_64.rpm\nglibc-langpack-quz-2.28-151.el8.x86_64.rpm\nglibc-langpack-raj-2.28-151.el8.x86_64.rpm\nglibc-langpack-ro-2.28-151.el8.x86_64.rpm\nglibc-langpack-ru-2.28-151.el8.x86_64.rpm\nglibc-langpack-rw-2.28-151.el8.x86_64.rpm\nglibc-langpack-sa-2.28-151.el8.x86_64.rpm\nglibc-langpack-sah-2.28-151.el8.x86_64.rpm\nglibc-langpack-sat-2.28-151.el8.x86_64.rpm\nglibc-langpack-sc-2.28-151.el8.x86_64.rpm\nglibc-langpack-sd-2.28-151.el8.x86_64.rpm\nglibc-langpack-se-2.28-151.el8.x86_64.rpm\nglibc-langpack-sgs-2.28-151.el8.x86_64.rpm\nglibc-langpack-shn-2.28-151.el8.x86_64.rpm\nglibc-langpack-shs-2.28-151.el8.x86_64.rpm\nglibc-langpack-si-2.28-151.el8.x86_64.rpm\nglibc-langpack-sid-2.28-151.el8.x86_64.rpm\nglibc-langpack-sk-2.28-151.el8.x86_64.rpm\nglibc-langpack-sl-2.28-151.el8.x86_64.rpm\nglibc-langpack-sm-2.28-151.el8.x86_64.rpm\nglibc-langpack-so-2.28-151.el8.x86_64.rpm\nglibc-langpack-sq-2.28-151.el8.x86_64.rpm\nglibc-langpack-sr-2.28-151.el8.x86_64.rpm\nglibc-langpack-ss-2.28-151.el8.x86_64.rpm\nglibc-langpack-st-2.28-151.el8.x86_64.rpm\nglibc-langpack-sv-2.28-151.el8.x86_64.rpm\nglibc-langpack-sw-2.28-151.el8.x86_64.rpm\nglibc-langpack-szl-2.28-151.el8.x86_64.rpm\nglibc-langpack-ta-2.28-151.el8.x86_64.rpm\nglibc-langpack-tcy-2.28-151.el8.x86_64.rpm\nglibc-langpack-te-2.28-151.el8.x86_64.rpm\nglibc-langpack-tg-2.28-151.el8.x86_64.rpm\nglibc-langpack-th-2.28-151.el8.x86_64.rpm\nglibc-langpack-the-2.28-151.el8.x86_64.rpm\nglibc-langpack-ti-2.28-151.el8.x86_64.rpm\nglibc-langpack-tig-2.28-151.el8.x86_64.rpm\nglibc-langpack-tk-2.28-151.el8.x86_64.rpm\nglibc-langpack-tl-2.28-151.el8.x86_64.rpm\nglibc-langpack-tn-2.28-151.el8.x86_64.rpm\nglibc-langpack-to-2.28-151.el8.x86_64.rpm\nglibc-langpack-tpi-2.28-151.el8.x86_64.rpm\nglibc-langpack-tr-2.28-151.el8.x86_64.rpm\nglibc-langpack-ts-2.28-151.el8.x86_64.rpm\nglibc-langpack-tt-2.28-151.el8.x86_64.rpm\nglibc-langpack-ug-2.28-151.el8.x86_64.rpm\nglibc-langpack-uk-2.28-151.el8.x86_64.rpm\nglibc-langpack-unm-2.28-151.el8.x86_64.rpm\nglibc-langpack-ur-2.28-151.el8.x86_64.rpm\nglibc-langpack-uz-2.28-151.el8.x86_64.rpm\nglibc-langpack-ve-2.28-151.el8.x86_64.rpm\nglibc-langpack-vi-2.28-151.el8.x86_64.rpm\nglibc-langpack-wa-2.28-151.el8.x86_64.rpm\nglibc-langpack-wae-2.28-151.el8.x86_64.rpm\nglibc-langpack-wal-2.28-151.el8.x86_64.rpm\nglibc-langpack-wo-2.28-151.el8.x86_64.rpm\nglibc-langpack-xh-2.28-151.el8.x86_64.rpm\nglibc-langpack-yi-2.28-151.el8.x86_64.rpm\nglibc-langpack-yo-2.28-151.el8.x86_64.rpm\nglibc-langpack-yue-2.28-151.el8.x86_64.rpm\nglibc-langpack-yuw-2.28-151.el8.x86_64.rpm\nglibc-langpack-zh-2.28-151.el8.x86_64.rpm\nglibc-langpack-zu-2.28-151.el8.x86_64.rpm\nglibc-locale-source-2.28-151.el8.x86_64.rpm\nglibc-minimal-langpack-2.28-151.el8.x86_64.rpm\nlibnsl-2.28-151.el8.i686.rpm\nlibnsl-2.28-151.el8.x86_64.rpm\nnscd-2.28-151.el8.x86_64.rpm\nnss_db-2.28-151.el8.i686.rpm\nnss_db-2.28-151.el8.x86_64.rpm\n\nRed Hat CodeReady Linux Builder (v. 8):\n\naarch64:\nglibc-benchtests-2.28-151.el8.aarch64.rpm\nglibc-debuginfo-2.28-151.el8.aarch64.rpm\nglibc-nss-devel-2.28-151.el8.aarch64.rpm\nglibc-static-2.28-151.el8.aarch64.rpm\nnss_hesiod-2.28-151.el8.aarch64.rpm\n\nppc64le:\nglibc-benchtests-2.28-151.el8.ppc64le.rpm\nglibc-debuginfo-2.28-151.el8.ppc64le.rpm\nglibc-debuginfo-common-2.28-151.el8.ppc64le.rpm\nglibc-nss-devel-2.28-151.el8.ppc64le.rpm\nglibc-static-2.28-151.el8.ppc64le.rpm\nnss_hesiod-2.28-151.el8.ppc64le.rpm\n\ns390x:\nglibc-benchtests-2.28-151.el8.s390x.rpm\nglibc-debuginfo-2.28-151.el8.s390x.rpm\nglibc-debuginfo-common-2.28-151.el8.s390x.rpm\nglibc-nss-devel-2.28-151.el8.s390x.rpm\nglibc-static-2.28-151.el8.s390x.rpm\nnss_hesiod-2.28-151.el8.s390x.rpm\n\nx86_64:\nglibc-benchtests-2.28-151.el8.x86_64.rpm\nglibc-debuginfo-2.28-151.el8.i686.rpm\nglibc-debuginfo-2.28-151.el8.x86_64.rpm\nglibc-debuginfo-common-2.28-151.el8.i686.rpm\nglibc-debuginfo-common-2.28-151.el8.x86_64.rpm\nglibc-nss-devel-2.28-151.el8.i686.rpm\nglibc-nss-devel-2.28-151.el8.x86_64.rpm\nglibc-static-2.28-151.el8.i686.rpm\nglibc-static-2.28-151.el8.x86_64.rpm\nnss_hesiod-2.28-151.el8.i686.rpm\nnss_hesiod-2.28-151.el8.x86_64.rpm\n\nThese packages are GPG signed by Red Hat for security. Our key and\ndetails on how to verify the signature are available from\nhttps://access.redhat.com/security/team/key/\n\n7. References:\n\nhttps://access.redhat.com/security/cve/CVE-2016-10228\nhttps://access.redhat.com/security/cve/CVE-2019-9169\nhttps://access.redhat.com/security/cve/CVE-2019-25013\nhttps://access.redhat.com/security/cve/CVE-2020-27618\nhttps://access.redhat.com/security/cve/CVE-2021-3326\nhttps://access.redhat.com/security/updates/classification/#moderate\nhttps://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/8.4_release_notes/\n\n8. Contact:\n\nThe Red Hat security contact is \u003csecalert@redhat.com\u003e. More contact\ndetails at https://access.redhat.com/security/team/contact/\n\nCopyright 2021 Red Hat, Inc. \n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1\n\niQIVAwUBYKPuENzjgjWX9erEAQi9vw//WZ4SvQsaE50S6H2/awuIPpTwqS9G8F1e\nRb3LxhoDtMidhwTtLX7GxvPUngmjG9gD9F2ySLYYltNYXGeI4RaRwwgaAJbJuaEG\nPOBR+tUKvTr/2qgNOuvvTkI5VIVSuFHL4szD4DLpntnD4fBVWTrKrSy4ZBmuH8lD\n65l2JvjTQgwxqFIIEbZz6quulCLYY7y080tLKJPCIqBTJWsS7VR3/4jo8YGwzls0\nu7zMsDcAhx7Y5mFSjZEds+KyT0kYQUW8N7SioeEKwfz3jteEbx7I+vyQUOYy9FZn\no13BjgNrfNktX6jV48d9Mj/t1+YGFYRu7GIuct9EjYLs4qE9LIKn8MCxVE3uwT+P\no4BlYwuXKZ5xBHBwU5nIElfttpyBynX6JuDXI9uw4On2p2ZWp4sqOwxm2Hpg3mK0\nBl5QR3sf3xIfnK8ZqEfR98H4QlY9bAwnLup2SgAxCiEPxsXlxBLeLRbaDlWBrvL2\n6KhUSLKCWNO3qAlDzVsqxbTXdbfVXkTut4bhdJz6tqfSD9fYpfqrMuSTQyKWMFm9\nFJ/l7yctRxZKC4D5CMrc+YAe9R/LLzokU83R9NA4NoViASuVXkYP6sBli0U9A8aw\nFTGqEOMIdVrT7C1C4NHM7dZgnAvjL22CbavMzjdnAySMRQxl5Je+vuK6jiZqTFwQ\nouzI0iwzGJs=R8FH\n-----END PGP SIGNATURE-----\n\n--\nRHSA-announce mailing list\nRHSA-announce@redhat.com\nhttps://listman.redhat.com/mailman/listinfo/rhsa-announce\n. \n\nBug Fix(es):\n\n* WMCO patch pub-key-hash annotation to Linux node (BZ#1945248)\n\n* LoadBalancer Service type with invalid external loadbalancer IP breaks\nthe datapath (BZ#1952917)\n\n* Telemetry info not completely available to identify windows nodes\n(BZ#1955319)\n\n* WMCO incorrectly shows node as ready after a failed configuration\n(BZ#1956412)\n\n* kube-proxy service terminated unexpectedly after recreated LB service\n(BZ#1963263)\n\n3. Solution:\n\nFor Windows Machine Config Operator upgrades, see the following\ndocumentation:\n\nhttps://docs.openshift.com/container-platform/4.7/windows_containers/window\ns-node-upgrades.html\n\n4. Bugs fixed (https://bugzilla.redhat.com/):\n\n1945248 - WMCO patch pub-key-hash annotation to Linux node\n1946538 - CVE-2021-25736 kubernetes: LoadBalancer Service type don\u0027t create a HNS policy for empty or invalid external loadbalancer IP, what could lead to MITM\n1952917 - LoadBalancer Service type with invalid external loadbalancer IP breaks the datapath\n1955319 - Telemetry info not completely available to identify windows nodes\n1956412 - WMCO incorrectly shows node as ready after a failed configuration\n1963263 - kube-proxy service terminated unexpectedly after recreated LB service\n\n5. Bugs fixed (https://bugzilla.redhat.com/):\n\n1937901 - CVE-2021-27918 golang: encoding/xml: infinite loop when using xml.NewTokenDecoder with a custom TokenReader\n1958341 - CVE-2021-31525 golang: net/http: panic in ReadRequest and ReadResponse when reading a very large header\n1965503 - CVE-2021-33196 golang: archive/zip: Malformed archive may cause panic or memory exhaustion\n1971445 - Release of OpenShift Serverless Serving 1.16.0\n1971448 - Release of OpenShift Serverless Eventing 1.16.0\n\n5. Description:\n\nRed Hat OpenShift Container Platform is Red Hat\u0027s cloud computing\nKubernetes application platform solution designed for on-premise or private\ncloud deployments. \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 container images for Red Hat OpenShift Container\nPlatform 4.7.13. See the following advisory for the RPM packages for this\nrelease:\n\nhttps://access.redhat.com/errata/RHSA-2021:2122\n\nSpace precludes documenting all of the container images in this advisory. \nSee the following Release Notes documentation, which will be updated\nshortly for this release, for details about these changes:\n\nhttps://docs.openshift.com/container-platform/4.7/release_notes/ocp-4-7-rel\nease-notes.html\n\nThis update fixes the following bug among others:\n\n* Previously, resources for the ClusterOperator were being created early in\nthe update process, which led to update failures when the ClusterOperator\nhad no status condition while Operators were updating. This bug fix changes\nthe timing of when these resources are created. As a result, updates can\ntake place without errors. (BZ#1959238)\n\nSecurity Fix(es):\n\n* gogo/protobuf: plugin/unmarshal/unmarshal.go lacks certain index\nvalidation (CVE-2021-3121)\n\nYou may download the oc tool and use it to inspect release image metadata\nas follows:\n\n(For x86_64 architecture)\n\n $ oc adm release info\nquay.io/openshift-release-dev/ocp-release:4.7.13-x86_64\n\nThe image digest is\nsha256:783a2c963f35ccab38e82e6a8c7fa954c3a4551e07d2f43c06098828dd986ed4\n\n(For s390x architecture)\n\n $ oc adm release info\nquay.io/openshift-release-dev/ocp-release:4.7.13-s390x\n\nThe image digest is\nsha256:4cf44e68413acad063203e1ee8982fd01d8b9c1f8643a5b31cd7ff341b3199cd\n\n(For ppc64le architecture)\n\n $ oc adm release info\nquay.io/openshift-release-dev/ocp-release:4.7.13-ppc64le\n\nThe image digest is\nsha256:d47ce972f87f14f1f3c5d50428d2255d1256dae3f45c938ace88547478643e36\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\n- -between-minor.html#understanding-upgrade-channels_updating-cluster-between\n- -minor\n\n3. Solution:\n\nFor OpenShift Container Platform 4.7 see the following documentation, which\nwill be updated shortly for this release, for important instructions on how\nto upgrade your cluster and fully apply this asynchronous errata update:\n\nhttps://docs.openshift.com/container-platform/4.7/release_notes/ocp-4-7-rel\nease-notes.html\n\nDetails on how to access this content are available at\nhttps://docs.openshift.com/container-platform/4.7/updating/updating-cluster\n- -cli.html\n\n4. Bugs fixed (https://bugzilla.redhat.com/):\n\n1921650 - CVE-2021-3121 gogo/protobuf: plugin/unmarshal/unmarshal.go lacks certain index validation\n1923268 - [Assisted-4.7] [Staging] Using two both spelling \"canceled\" \"cancelled\"\n1947216 - [AWS] Missing iam:ListAttachedRolePolicies permission in permissions.go\n1953963 - Enable/Disable host operations returns cluster resource with incomplete hosts list\n1957749 - ovn-kubernetes pod should have CPU and memory requests set but not limits\n1959238 - CVO creating cloud-controller-manager too early causing upgrade failures\n1960103 - SR-IOV obliviously reboot the node\n1961941 - Local Storage Operator using LocalVolume CR fails to create PV\u0027s when backend storage failure is simulated\n1962302 - packageserver clusteroperator does not set reason or message for Available condition\n1962312 - Deployment considered unhealthy despite being available and at latest generation\n1962435 - Public DNS records were not deleted when destroying a cluster which is using byo private hosted zone\n1963115 - Test verify /run filesystem contents failing\n\n5. Description:\n\nRed Hat Advanced Cluster Management for Kubernetes 2.3.0 images\n\nRed Hat Advanced Cluster Management for Kubernetes provides the\ncapabilities to address common challenges that administrators and site\nreliability engineers face as they work across a range of public and\nprivate cloud environments. Clusters and applications are all visible and\nmanaged from a single console\u2014with security policy built in. See\nthe following Release Notes documentation, which will be updated shortly\nfor this release, for additional details about this release:\n\nhttps://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_mana\ngement_for_kubernetes/2.3/html/release_notes/\n\nSecurity:\n\n* fastify-reply-from: crafted URL allows prefix scape of the proxied\nbackend service (CVE-2021-21321)\n\n* fastify-http-proxy: crafted URL allows prefix scape of the proxied\nbackend service (CVE-2021-21322)\n\n* nodejs-netmask: improper input validation of octal input data\n(CVE-2021-28918)\n\n* redis: Integer overflow via STRALGO LCS command (CVE-2021-29477)\n\n* redis: Integer overflow via COPY command for large intsets\n(CVE-2021-29478)\n\n* nodejs-glob-parent: Regular expression denial of service (CVE-2020-28469)\n\n* nodejs-lodash: ReDoS via the toNumber, trim and trimEnd functions\n(CVE-2020-28500)\n\n* golang.org/x/text: Panic in language.ParseAcceptLanguage while parsing\n- -u- extension (CVE-2020-28851)\n\n* golang.org/x/text: Panic in language.ParseAcceptLanguage while processing\nbcp47 tag (CVE-2020-28852)\n\n* nodejs-ansi_up: XSS due to insufficient URL sanitization (CVE-2021-3377)\n\n* oras: zip-slip vulnerability via oras-pull (CVE-2021-21272)\n\n* redis: integer overflow when configurable limit for maximum supported\nbulk input size is too big on 32-bit platforms (CVE-2021-21309)\n\n* nodejs-lodash: command injection via template (CVE-2021-23337)\n\n* nodejs-hosted-git-info: Regular Expression denial of service via\nshortcutMatch in fromUrl() (CVE-2021-23362)\n\n* browserslist: parsing of invalid queries could result in Regular\nExpression Denial of Service (ReDoS) (CVE-2021-23364)\n\n* nodejs-postcss: Regular expression denial of service during source map\nparsing (CVE-2021-23368)\n\n* nodejs-handlebars: Remote code execution when compiling untrusted compile\ntemplates with strict:true option (CVE-2021-23369)\n\n* nodejs-postcss: ReDoS via getAnnotationURL() and loadAnnotation() in\nlib/previous-map.js (CVE-2021-23382)\n\n* nodejs-handlebars: Remote code execution when compiling untrusted compile\ntemplates with compat:true option (CVE-2021-23383)\n\n* openssl: integer overflow in CipherUpdate (CVE-2021-23840)\n\n* openssl: NULL pointer dereference in X509_issuer_and_serial_hash()\n(CVE-2021-23841)\n\n* nodejs-ua-parser-js: ReDoS via malicious User-Agent header\n(CVE-2021-27292)\n\n* grafana: snapshot feature allow an unauthenticated remote attacker to\ntrigger a DoS via a remote API call (CVE-2021-27358)\n\n* nodejs-is-svg: ReDoS via malicious string (CVE-2021-28092)\n\n* nodejs-netmask: incorrectly parses an IP address that has octal integer\nwith invalid character (CVE-2021-29418)\n\n* ulikunitz/xz: Infinite loop in readUvarint allows for denial of service\n(CVE-2021-29482)\n\n* normalize-url: ReDoS for data URLs (CVE-2021-33502)\n\n* nodejs-trim-newlines: ReDoS in .end() method (CVE-2021-33623)\n\n* nodejs-path-parse: ReDoS via splitDeviceRe, splitTailRe and splitPathRe\n(CVE-2021-23343)\n\n* html-parse-stringify: Regular Expression DoS (CVE-2021-23346)\n\n* openssl: incorrect SSLv2 rollback protection (CVE-2021-23839)\n\nFor more details about the security issues, including the impact, a CVSS\nscore, acknowledgments, and other related information, refer to the CVE\npages listed in the References section. \n\nBugs:\n\n* RFE Make the source code for the endpoint-metrics-operator public (BZ#\n1913444)\n\n* cluster became offline after apiserver health check (BZ# 1942589)\n\n3. Solution:\n\nBefore applying this update, make sure all previously released errata\nrelevant to your system have been applied. Bugs fixed (https://bugzilla.redhat.com/):\n\n1913333 - CVE-2020-28851 golang.org/x/text: Panic in language.ParseAcceptLanguage while parsing -u- extension\n1913338 - CVE-2020-28852 golang.org/x/text: Panic in language.ParseAcceptLanguage while processing bcp47 tag\n1913444 - RFE Make the source code for the endpoint-metrics-operator public\n1921286 - CVE-2021-21272 oras: zip-slip vulnerability via oras-pull\n1927520 - RHACM 2.3.0 images\n1928937 - CVE-2021-23337 nodejs-lodash: command injection via template\n1928954 - CVE-2020-28500 nodejs-lodash: ReDoS via the toNumber, trim and trimEnd functions\n1930294 - CVE-2021-23839 openssl: incorrect SSLv2 rollback protection\n1930310 - CVE-2021-23841 openssl: NULL pointer dereference in X509_issuer_and_serial_hash()\n1930324 - CVE-2021-23840 openssl: integer overflow in CipherUpdate\n1932634 - CVE-2021-21309 redis: integer overflow when configurable limit for maximum supported bulk input size is too big on 32-bit platforms\n1936427 - CVE-2021-3377 nodejs-ansi_up: XSS due to insufficient URL sanitization\n1939103 - CVE-2021-28092 nodejs-is-svg: ReDoS via malicious string\n1940196 - View Resource YAML option shows 404 error when reviewing a Subscription for an application\n1940613 - CVE-2021-27292 nodejs-ua-parser-js: ReDoS via malicious User-Agent header\n1941024 - CVE-2021-27358 grafana: snapshot feature allow an unauthenticated remote attacker to trigger a DoS via a remote API call\n1941675 - CVE-2021-23346 html-parse-stringify: Regular Expression DoS\n1942178 - CVE-2021-21321 fastify-reply-from: crafted URL allows prefix scape of the proxied backend service\n1942182 - CVE-2021-21322 fastify-http-proxy: crafted URL allows prefix scape of the proxied backend service\n1942589 - cluster became offline after apiserver health check\n1943208 - CVE-2021-23362 nodejs-hosted-git-info: Regular Expression denial of service via shortcutMatch in fromUrl()\n1944822 - CVE-2021-29418 nodejs-netmask: incorrectly parses an IP address that has octal integer with invalid character\n1944827 - CVE-2021-28918 nodejs-netmask: improper input validation of octal input data\n1945459 - CVE-2020-28469 nodejs-glob-parent: Regular expression denial of service\n1948761 - CVE-2021-23369 nodejs-handlebars: Remote code execution when compiling untrusted compile templates with strict:true option\n1948763 - CVE-2021-23368 nodejs-postcss: Regular expression denial of service during source map parsing\n1954150 - CVE-2021-23382 nodejs-postcss: ReDoS via getAnnotationURL() and loadAnnotation() in lib/previous-map.js\n1954368 - CVE-2021-29482 ulikunitz/xz: Infinite loop in readUvarint allows for denial of service\n1955619 - CVE-2021-23364 browserslist: parsing of invalid queries could result in Regular Expression Denial of Service (ReDoS)\n1956688 - CVE-2021-23383 nodejs-handlebars: Remote code execution when compiling untrusted compile templates with compat:true option\n1956818 - CVE-2021-23343 nodejs-path-parse: ReDoS via splitDeviceRe, splitTailRe and splitPathRe\n1957410 - CVE-2021-29477 redis: Integer overflow via STRALGO LCS command\n1957414 - CVE-2021-29478 redis: Integer overflow via COPY command for large intsets\n1964461 - CVE-2021-33502 normalize-url: ReDoS for data URLs\n1966615 - CVE-2021-33623 nodejs-trim-newlines: ReDoS in .end() method\n1968122 - clusterdeployment fails because hiveadmission sc does not have correct permissions\n1972703 - Subctl fails to join cluster, since it cannot auto-generate a valid cluster id\n1983131 - Defragmenting an etcd member doesn\u0027t reduce the DB size (7.5GB) on a setup with ~1000 spoke clusters\n\n5. Description:\n\nService Telemetry Framework (STF) provides automated collection of\nmeasurements and data from remote clients, such as Red Hat OpenStack\nPlatform or third-party nodes. \nDockerfiles and scripts should be amended either to refer to this new image\nspecifically, or to the latest image generally. Bugs fixed (https://bugzilla.redhat.com/):\n\n2107342 - CVE-2022-30631 golang: compress/gzip: stack exhaustion in Reader.Read\n\n5", "sources": [ { "db": "NVD", "id": "CVE-2019-25013" }, { "db": "JVNDB", "id": "JVNDB-2019-016179" }, { "db": "VULMON", "id": "CVE-2019-25013" }, { "db": "PACKETSTORM", "id": "162634" }, { "db": "PACKETSTORM", "id": "162837" }, { "db": "PACKETSTORM", "id": "163257" }, { "db": "PACKETSTORM", "id": "163496" }, { "db": "PACKETSTORM", "id": "162877" }, { "db": "PACKETSTORM", "id": "163747" }, { "db": "PACKETSTORM", "id": "168011" } ], "trust": 2.34 }, "external_ids": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/external_ids#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "db": "NVD", "id": "CVE-2019-25013", "trust": 4.0 }, { "db": "ICS CERT", "id": "ICSA-23-166-10", "trust": 0.8 }, { "db": "JVN", "id": "JVNVU99464755", "trust": 0.8 }, { "db": "JVNDB", "id": "JVNDB-2019-016179", "trust": 0.8 }, { "db": "PACKETSTORM", "id": "162634", "trust": 0.7 }, { "db": "PACKETSTORM", "id": "162837", "trust": 0.7 }, { "db": "PACKETSTORM", "id": "163496", "trust": 0.7 }, { "db": "PACKETSTORM", "id": "162877", "trust": 0.7 }, { "db": "PACKETSTORM", "id": "163747", "trust": 0.7 }, { "db": "PACKETSTORM", "id": "168011", "trust": 0.7 }, { "db": "PACKETSTORM", "id": "163789", "trust": 0.6 }, { "db": "PACKETSTORM", "id": "163276", "trust": 0.6 }, { "db": "PACKETSTORM", "id": "166279", "trust": 0.6 }, { "db": "PACKETSTORM", "id": "163267", "trust": 0.6 }, { "db": "PACKETSTORM", "id": "161254", "trust": 0.6 }, { "db": "PACKETSTORM", "id": "164192", "trust": 0.6 }, { "db": "PACKETSTORM", "id": "163406", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.0868", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2022.6426", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.2228", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.2180", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2022.0875", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.0373", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.0728", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.0743", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.2711", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.1866", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.3141", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.4058", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.2657", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.1820", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2022.5140", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.1743", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2022.4222", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.2604", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2022.1025", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.2365", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.2781", "trust": 0.6 }, { "db": "CS-HELP", "id": "SB2022011038", "trust": 0.6 }, { "db": "CS-HELP", "id": "SB2022031430", "trust": 0.6 }, { "db": "CS-HELP", "id": "SB2021071310", "trust": 0.6 }, { "db": "CS-HELP", "id": "SB2021070604", "trust": 0.6 }, { "db": "CS-HELP", "id": "SB2021062703", "trust": 0.6 }, { "db": "CS-HELP", "id": "SB2021062315", "trust": 0.6 }, { "db": "CS-HELP", "id": "SB2021071516", "trust": 0.6 }, { "db": "CS-HELP", "id": "SB2021122914", "trust": 0.6 }, { "db": "CS-HELP", "id": "SB2021092220", "trust": 0.6 }, { "db": "CNNVD", "id": "CNNVD-202101-048", "trust": 0.6 }, { "db": "VULMON", "id": "CVE-2019-25013", "trust": 0.1 }, { "db": "PACKETSTORM", "id": "163257", "trust": 0.1 } ], "sources": [ { "db": "VULMON", "id": "CVE-2019-25013" }, { "db": "JVNDB", "id": "JVNDB-2019-016179" }, { "db": "PACKETSTORM", "id": "162634" }, { "db": "PACKETSTORM", "id": "162837" }, { "db": "PACKETSTORM", "id": "163257" }, { "db": "PACKETSTORM", "id": "163496" }, { "db": "PACKETSTORM", "id": "162877" }, { "db": "PACKETSTORM", "id": "163747" }, { "db": "PACKETSTORM", "id": "168011" }, { "db": "CNNVD", "id": "CNNVD-202101-048" }, { "db": "NVD", "id": "CVE-2019-25013" } ] }, "id": "VAR-202101-0119", "iot": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/iot#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": true, "sources": [ { "db": "VARIoT devices database", "id": null } ], "trust": 0.465277775 }, "last_update_date": "2024-09-19T20:40:43.272000Z", "patch": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/patch#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "title": "Bug\u00a024973 NetAppNetApp\u00a0Advisory", "trust": 0.8, "url": "https://www.broadcom.com/" }, { "title": "GNU C Library Buffer error vulnerability fix", "trust": 0.6, "url": "http://123.124.177.30/web/xxk/bdxqById.tag?id=138312" }, { "title": "Debian CVElist Bug Report Logs: glibc: CVE-2019-25013", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=debian_cvelist_bugreportlogs\u0026qid=7073abdc63eae799f90555726b8fbe41" }, { "title": "Red Hat: Moderate: glibc security and bug fix update", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=red_hat_security_advisories\u0026qid=RHSA-20210348 - Security Advisory" }, { "title": "Amazon Linux 2: ALAS2-2021-1599", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=amazon_linux2\u0026qid=ALAS2-2021-1599" }, { "title": "Ubuntu Security Notice: USN-5768-1: GNU C Library vulnerabilities", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=ubuntu_security_notice\u0026qid=USN-5768-1" }, { "title": "Arch Linux Issues: ", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=arch_linux_issues\u0026qid=CVE-2019-25013 log" }, { "title": "Amazon Linux AMI: ALAS-2021-1511", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=amazon_linux_ami\u0026qid=ALAS-2021-1511" }, { "title": "Arch Linux Advisories: [ASA-202102-18] glibc: denial of service", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=arch_linux_advisories\u0026qid=ASA-202102-18" }, { "title": "Arch Linux Advisories: [ASA-202102-17] lib32-glibc: denial of service", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=arch_linux_advisories\u0026qid=ASA-202102-17" }, { "title": "Red Hat: Moderate: Red Hat Advanced Cluster Management 2.1.3 security and bug fix update", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=red_hat_security_advisories\u0026qid=RHSA-20210607 - Security Advisory" }, { "title": "Amazon Linux 2: ALAS2-2021-1605", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=amazon_linux2\u0026qid=ALAS2-2021-1605" }, { "title": "Ubuntu Security Notice: USN-5310-1: GNU C Library vulnerabilities", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=ubuntu_security_notice\u0026qid=USN-5310-1" }, { "title": "Red Hat: Important: Service Telemetry Framework 1.4 security update", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=red_hat_security_advisories\u0026qid=RHSA-20225924 - Security Advisory" }, { "title": "IBM: Security Bulletin: Cloud Pak for Security contains security vulnerabilities", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=ibm_psirt_blog\u0026qid=08f19f0be4d5dcf7486e5abcdb671477" }, { "title": "Red Hat: Moderate: OpenShift Container Platform 4.10.3 security update", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=red_hat_security_advisories\u0026qid=RHSA-20220056 - Security Advisory" }, { "title": "Siemens Security Advisories: Siemens Security Advisory", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=siemens_security_advisories\u0026qid=ec6577109e640dac19a6ddb978afe82d" }, { "title": "", "trust": 0.1, "url": "https://github.com/Live-Hack-CVE/CVE-2019-25013 " }, { "title": "ecr-api", "trust": 0.1, "url": "https://github.com/YaleSpinup/ecr-api " }, { "title": "sanction", "trust": 0.1, "url": "https://github.com/ctc-oss/sanction " }, { "title": "release-the-code-litecoin", "trust": 0.1, "url": "https://github.com/brandoncamenisch/release-the-code-litecoin " }, { "title": "interview_project", "trust": 0.1, "url": "https://github.com/domyrtille/interview_project " }, { "title": "trivy-multiscanner", "trust": 0.1, "url": "https://github.com/onzack/trivy-multiscanner " }, { "title": "spring-boot-app-with-log4j-vuln", "trust": 0.1, "url": "https://github.com/nedenwalker/spring-boot-app-with-log4j-vuln " }, { "title": "giant-squid", "trust": 0.1, "url": "https://github.com/dispera/giant-squid " }, { "title": "devops-demo", "trust": 0.1, "url": "https://github.com/epequeno/devops-demo " }, { "title": "spring-boot-app-using-gradle", "trust": 0.1, "url": "https://github.com/nedenwalker/spring-boot-app-using-gradle " }, { "title": "xyz-solutions", "trust": 0.1, "url": "https://github.com/sauliuspr/xyz-solutions " }, { "title": "myapp-container-jaxrs", "trust": 0.1, "url": "https://github.com/akiraabe/myapp-container-jaxrs " } ], "sources": [ { "db": "VULMON", "id": "CVE-2019-25013" }, { "db": "JVNDB", "id": "JVNDB-2019-016179" }, { "db": "CNNVD", "id": "CNNVD-202101-048" } ] }, "problemtype_data": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/problemtype_data#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "problemtype": "CWE-125", "trust": 1.0 }, { "problemtype": "Out-of-bounds read (CWE-125) [NVD evaluation ]", "trust": 0.8 } ], "sources": [ { "db": "JVNDB", "id": "JVNDB-2019-016179" }, { "db": "NVD", "id": "CVE-2019-25013" } ] }, "references": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/references#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "trust": 2.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-25013" }, { "trust": 1.6, "url": "https://security.netapp.com/advisory/ntap-20210205-0004/" }, { "trust": 1.6, "url": "https://security.gentoo.org/glsa/202107-07" }, { "trust": 1.6, "url": "https://www.oracle.com/security-alerts/cpuapr2022.html" }, { "trust": 1.6, "url": "https://lists.debian.org/debian-lts-announce/2022/10/msg00021.html" }, { "trust": 1.6, "url": "https://sourceware.org/bugzilla/show_bug.cgi?id=24973" }, { "trust": 1.0, "url": "https://lists.apache.org/thread.html/r32d767ac804e9b8aad4355bb85960a6a1385eab7afff549a5e98660f%40%3cjira.kafka.apache.org%3e" }, { "trust": 1.0, "url": "https://lists.apache.org/thread.html/r448bb851cc8e6e3f93f3c28c70032b37062625d81214744474ac49e7%40%3cdev.kafka.apache.org%3e" }, { "trust": 1.0, "url": "https://lists.apache.org/thread.html/r4806a391091e082bdea17266452ca656ebc176e51bb3932733b3a0a2%40%3cjira.kafka.apache.org%3e" }, { "trust": 1.0, "url": "https://lists.apache.org/thread.html/r499e4f96d0b5109ef083f2feccd33c51650c1b7d7068aa3bd47efca9%40%3cjira.kafka.apache.org%3e" }, { "trust": 1.0, "url": "https://lists.apache.org/thread.html/r5af4430421bb6f9973294691a7904bbd260937e9eef96b20556f43ff%40%3cjira.kafka.apache.org%3e" }, { "trust": 1.0, "url": "https://lists.apache.org/thread.html/r750eee18542bc02bd8350861c424ee60a9b9b225568fa09436a37ece%40%3cissues.zookeeper.apache.org%3e" }, { "trust": 1.0, "url": "https://lists.apache.org/thread.html/r7a2e94adfe0a2f0a1d42e4927e8c32ecac97d37db9cb68095fe9ddbc%40%3cdev.zookeeper.apache.org%3e" }, { "trust": 1.0, "url": "https://lists.apache.org/thread.html/rd2354f9ccce41e494fbadcbc5ad87218de6ec0fff8a7b54c8462226c%40%3cissues.zookeeper.apache.org%3e" }, { "trust": 1.0, "url": "https://lists.apache.org/thread.html/rf9fa47ab66495c78bb4120b0754dd9531ca2ff0430f6685ac9b07772%40%3cdev.mina.apache.org%3e" }, { "trust": 1.0, "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/4y6tx47p47kabsfol26fldnvcwxdkdez/" }, { "trust": 1.0, "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/tvcunlq3hxgs4vpuqkwtjgraw2ktfgxs/" }, { "trust": 1.0, "url": "https://sourceware.org/git/?p=glibc.git%3ba=commit%3bh=ee7a3144c9922808181009b7b3e50e852fb4999b" }, { "trust": 0.8, "url": "http://jvn.jp/vu/jvnvu99464755/index.html" }, { "trust": 0.8, "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-23-166-10" }, { "trust": 0.7, "url": "https://access.redhat.com/security/cve/cve-2019-25013" }, { "trust": 0.7, "url": "https://access.redhat.com/security/team/contact/" }, { "trust": 0.7, "url": "https://access.redhat.com/security/cve/cve-2021-3326" }, { "trust": 0.7, "url": "https://listman.redhat.com/mailman/listinfo/rhsa-announce" }, { "trust": 0.7, "url": "https://nvd.nist.gov/vuln/detail/cve-2016-10228" }, { "trust": 0.7, "url": "https://access.redhat.com/security/cve/cve-2016-10228" }, { "trust": 0.7, "url": "https://bugzilla.redhat.com/):" }, { "trust": 0.7, "url": "https://access.redhat.com/security/cve/cve-2020-27618" }, { "trust": 0.7, "url": "https://access.redhat.com/security/cve/cve-2019-9169" }, { "trust": 0.6, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-9169" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2020-15358" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2020-13434" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2020-29362" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2020-29361" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2020-8927" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2020-29363" }, { "trust": 0.6, "url": "https://lists.apache.org/thread.html/r5af4430421bb6f9973294691a7904bbd260937e9eef96b20556f43ff@%3cjira.kafka.apache.org%3e" }, { "trust": 0.6, "url": "https://lists.apache.org/thread.html/r7a2e94adfe0a2f0a1d42e4927e8c32ecac97d37db9cb68095fe9ddbc@%3cdev.zookeeper.apache.org%3e" }, { "trust": 0.6, "url": "https://lists.apache.org/thread.html/r448bb851cc8e6e3f93f3c28c70032b37062625d81214744474ac49e7@%3cdev.kafka.apache.org%3e" }, { "trust": 0.6, "url": "https://sourceware.org/git/?p=glibc.git;a=commit;h=ee7a3144c9922808181009b7b3e50e852fb4999b" }, { "trust": 0.6, "url": "https://lists.apache.org/thread.html/r4806a391091e082bdea17266452ca656ebc176e51bb3932733b3a0a2@%3cjira.kafka.apache.org%3e" }, { "trust": 0.6, "url": "https://lists.apache.org/thread.html/rf9fa47ab66495c78bb4120b0754dd9531ca2ff0430f6685ac9b07772@%3cdev.mina.apache.org%3e" }, { "trust": 0.6, "url": "https://lists.apache.org/thread.html/rd2354f9ccce41e494fbadcbc5ad87218de6ec0fff8a7b54c8462226c@%3cissues.zookeeper.apache.org%3e" }, { "trust": 0.6, "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/tvcunlq3hxgs4vpuqkwtjgraw2ktfgxs/" }, { "trust": 0.6, "url": "https://lists.apache.org/thread.html/r750eee18542bc02bd8350861c424ee60a9b9b225568fa09436a37ece@%3cissues.zookeeper.apache.org%3e" }, { "trust": 0.6, "url": "https://lists.apache.org/thread.html/r499e4f96d0b5109ef083f2feccd33c51650c1b7d7068aa3bd47efca9@%3cjira.kafka.apache.org%3e" }, { "trust": 0.6, "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4y6tx47p47kabsfol26fldnvcwxdkdez/" }, { "trust": 0.6, "url": "https://lists.apache.org/thread.html/r32d767ac804e9b8aad4355bb85960a6a1385eab7afff549a5e98660f@%3cjira.kafka.apache.org%3e" }, { "trust": 0.6, "url": "https://packetstormsecurity.com/files/164192/red-hat-security-advisory-2021-3556-01.html" }, { "trust": 0.6, "url": "https://packetstormsecurity.com/files/168011/red-hat-security-advisory-2022-5924-01.html" }, { "trust": 0.6, "url": "https://packetstormsecurity.com/files/163789/red-hat-security-advisory-2021-3119-01.html" }, { "trust": 0.6, "url": "https://www.ibm.com/blogs/psirt/security-bulletin-cloud-pak-for-security-contains-security-vulnerabilities/" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.1866" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.2657" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.1743" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.1820" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.2711" }, { "trust": 0.6, "url": "https://www.cybersecurity-help.cz/vdb/sb2021071310" }, { "trust": 0.6, "url": "https://packetstormsecurity.com/files/163747/red-hat-security-advisory-2021-3016-01.html" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.2781" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2022.5140" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.0373/" }, { "trust": 0.6, "url": "https://www.cybersecurity-help.cz/vdb/sb2022031430" }, { "trust": 0.6, "url": "https://packetstormsecurity.com/files/166279/red-hat-security-advisory-2022-0056-01.html" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.2365" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.2180" }, { "trust": 0.6, "url": "https://www.cybersecurity-help.cz/vdb/sb2021122914" }, { "trust": 0.6, "url": "https://packetstormsecurity.com/files/162634/red-hat-security-advisory-2021-1585-01.html" }, { "trust": 0.6, "url": "https://packetstormsecurity.com/files/163276/red-hat-security-advisory-2021-2543-01.html" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2022.0875" }, { "trust": 0.6, "url": "https://vigilance.fr/vulnerability/glibc-out-of-bounds-memory-reading-via-iconv-euc-kr-encoding-34360" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2022.1025" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.0728" }, { "trust": 0.6, "url": "https://packetstormsecurity.com/files/163496/red-hat-security-advisory-2021-2705-01.html" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.0743" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.2228" }, { "trust": 0.6, "url": "https://www.cybersecurity-help.cz/vdb/sb2021062703" }, { "trust": 0.6, "url": "https://www.cybersecurity-help.cz/vdb/sb2021092220" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.0868" }, { "trust": 0.6, "url": "https://www.ibm.com/support/pages/node/6520474" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.2604" }, { "trust": 0.6, "url": "https://packetstormsecurity.com/files/162837/red-hat-security-advisory-2021-2136-01.html" }, { "trust": 0.6, "url": "https://packetstormsecurity.com/files/163267/red-hat-security-advisory-2021-2532-01.html" }, { "trust": 0.6, "url": "https://www.cybersecurity-help.cz/vdb/sb2022011038" }, { "trust": 0.6, "url": "https://packetstormsecurity.com/files/161254/red-hat-security-advisory-2021-0348-01.html" }, { "trust": 0.6, "url": "https://www.cybersecurity-help.cz/vdb/sb2021070604" }, { "trust": 0.6, "url": "https://www.cybersecurity-help.cz/vdb/sb2021071516" }, { "trust": 0.6, "url": "https://packetstormsecurity.com/files/162877/red-hat-security-advisory-2021-2121-01.html" }, { "trust": 0.6, "url": "https://www.cybersecurity-help.cz/vdb/sb2021062315" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.4058" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2022.4222" }, { "trust": 0.6, "url": "https://packetstormsecurity.com/files/163406/gentoo-linux-security-advisory-202107-07.html" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.3141" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2022.6426" }, { "trust": 0.5, "url": "https://access.redhat.com/security/updates/classification/#moderate" }, { "trust": 0.5, "url": "https://access.redhat.com/security/cve/cve-2020-8286" }, { "trust": 0.5, "url": "https://access.redhat.com/security/cve/cve-2020-28196" }, { "trust": 0.5, "url": "https://access.redhat.com/security/cve/cve-2020-8231" }, { "trust": 0.5, "url": "https://access.redhat.com/security/cve/cve-2020-8285" }, { "trust": 0.5, "url": "https://access.redhat.com/security/cve/cve-2019-2708" }, { "trust": 0.5, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-2708" }, { "trust": 0.5, "url": "https://access.redhat.com/security/cve/cve-2020-8284" }, { "trust": 0.4, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-27618" }, { "trust": 0.4, "url": "https://access.redhat.com/security/cve/cve-2021-20305" }, { "trust": 0.4, "url": "https://access.redhat.com/security/cve/cve-2019-3842" }, { "trust": 0.4, "url": "https://access.redhat.com/security/cve/cve-2020-13776" }, { "trust": 0.4, "url": "https://access.redhat.com/security/cve/cve-2020-24977" }, { "trust": 0.4, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-13434" }, { "trust": 0.4, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-3842" }, { "trust": 0.4, "url": "https://access.redhat.com/security/cve/cve-2017-14502" }, { "trust": 0.4, "url": "https://nvd.nist.gov/vuln/detail/cve-2017-14502" }, { "trust": 0.3, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-3326" }, { "trust": 0.3, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-13776" }, { "trust": 0.3, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-29362" }, { "trust": 0.3, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-15358" }, { "trust": 0.3, "url": "https://access.redhat.com/security/cve/cve-2021-27219" }, { "trust": 0.3, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-29361" }, { "trust": 0.3, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-28196" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-14347" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-36322" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-12114" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-25712" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-12114" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-13543" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-27835" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-9951" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-25704" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-3121" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-10878" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-19528" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-9948" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2019-13012" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-0431" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-26116" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-14363" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-13584" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-26137" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2019-18811" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-14360" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2019-19528" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-12464" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-14314" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-12362" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-14356" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-27619" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-27786" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-25643" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-9983" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-3177" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-24394" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-0431" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-0342" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-18811" }, { "trust": 0.2, "url": "https://docs.openshift.com/container-platform/4.7/release_notes/ocp-4-7-rel" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-14345" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-14344" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2019-19523" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-23336" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-14362" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-14361" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-10543" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-25285" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-35508" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-12362" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-25212" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-19523" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-28974" }, { "trust": 0.2, "url": "https://issues.jboss.org/):" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-10543" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-15437" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-13012" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-25284" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-14346" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-10878" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-11608" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-11608" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-12464" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-8284" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-27219" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-8285" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-8286" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-8927" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-29363" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-8231" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-3449" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-3450" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-24977" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2019-20454" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2019-13050" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-3520" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-3537" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-3518" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-13050" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-3516" }, { "trust": 0.2, "url": "https://access.redhat.com/security/updates/classification/#important" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-3517" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2018-1000858" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2019-14889" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-1730" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-3541" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2019-13627" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2018-1000858" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-20454" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-13627" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-14889" }, { "trust": 0.1, "url": "https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/8.4_release_notes/" }, { "trust": 0.1, "url": "https://access.redhat.com/articles/11258" }, { "trust": 0.1, "url": "https://access.redhat.com/security/team/key/" }, { "trust": 0.1, "url": "https://access.redhat.com/errata/rhsa-2021:1585" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-14346" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-14345" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-13543" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-13584" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-14347" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-14360" }, { "trust": 0.1, "url": "https://access.redhat.com/errata/rhsa-2021:2136" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-14314" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-14344" }, { "trust": 0.1, "url": "https://docs.openshift.com/container-platform/4.7/logging/cluster-logging-u" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-14356" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-25736" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-3450" }, { "trust": 0.1, "url": "https://access.redhat.com/errata/rhsa-2021:2130" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-20305" }, { "trust": 0.1, "url": "https://docs.openshift.com/container-platform/4.7/windows_containers/window" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-25736" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-3449" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-27918" }, { "trust": 0.1, "url": "https://access.redhat.com/documentation/en-us/openshift_container_platform/" }, { "trust": 0.1, "url": "https://access.redhat.com/errata/rhsa-2021:2705" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-31525" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-31525" }, { "trust": 0.1, "url": "https://access.redhat.com/documentation/en-us/openshift_container_platform/4.7/html/serverless/index" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-27918" }, { "trust": 0.1, "url": "https://access.redhat.com/documentation/en-us/openshift_container_platform/4.6/html/serverless/index" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-33196" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-33196" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-25039" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-15586" }, { "trust": 0.1, "url": "https://docs.openshift.com/container-platform/4.7/updating/updating-cluster" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-25037" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-36242" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-25037" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-28935" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-25034" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-16845" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-25035" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-14866" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-25038" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-14866" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-21645" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-25040" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-27783" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-24330" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-25042" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-25042" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-25038" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-25659" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-25032" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-25041" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-25036" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-25032" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-21643" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-25215" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-24331" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-25036" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-30465" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-25035" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-21644" }, { "trust": 0.1, "url": "https://access.redhat.com/errata/rhsa-2021:2121" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-24332" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-25039" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-25040" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-25041" }, { "trust": 0.1, "url": "https://access.redhat.com/errata/rhsa-2021:2122" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-21642" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-25034" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-28469" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-28500" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-20934" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-29418" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-28852" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-33034" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-28092" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-15903" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2018-20843" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-28851" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-1730" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-33909" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-29482" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-23337" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-32399" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-27358" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-19906" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-23369" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-21321" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-23368" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-11668" }, { "trust": 0.1, "url": "https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_mana" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-23362" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-23364" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-23343" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-21309" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-33502" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-23841" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-23383" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-28918" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-28851" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-3560" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-28852" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-23840" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-33033" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-20934" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-25217" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-28469" }, { "trust": 0.1, "url": "https://access.redhat.com/errata/rhsa-2021:3016" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-3377" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-20271" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-28500" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-21272" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-29477" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-27292" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-23346" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-29478" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-11668" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-23839" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-19906" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-33623" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2018-20843" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-21322" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-23382" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-15903" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-33910" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-37750" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-3867" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-9805" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-3894" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-9807" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-3899" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-30761" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-8743" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8743" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8823" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-3900" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-9894" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-33938" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8782" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8771" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-9952" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8846" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2022-24407" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-9915" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2022-1271" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8783" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-36222" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-8625" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8813" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-9806" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-3885" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-9802" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8764" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-22946" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8769" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8710" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-10018" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-9895" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8811" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-8710" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8819" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-3862" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2018-25032" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-3868" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-3895" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-3865" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-33930" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-14391" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-3864" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-9862" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-33929" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8835" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8816" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-3897" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8808" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8625" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-27218" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-22947" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8766" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-11793" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-9803" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-3521" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-9850" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-30666" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-33928" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2022-30631" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8820" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-9893" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2022-23852" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8844" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-20807" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-3902" }, { "trust": 0.1, "url": "https://access.redhat.com/errata/rhsa-2022:5924" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8814" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8812" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8815" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-9843" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-3901" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2019-8720" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2018-25032" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-30762" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-20807" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-9925" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2022-0778" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-15503" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-8720" } ], "sources": [ { "db": "JVNDB", "id": "JVNDB-2019-016179" }, { "db": "PACKETSTORM", "id": "162634" }, { "db": "PACKETSTORM", "id": "162837" }, { "db": "PACKETSTORM", "id": "163257" }, { "db": "PACKETSTORM", "id": "163496" }, { "db": "PACKETSTORM", "id": "162877" }, { "db": "PACKETSTORM", "id": "163747" }, { "db": "PACKETSTORM", "id": "168011" }, { "db": "CNNVD", "id": "CNNVD-202101-048" }, { "db": "NVD", "id": "CVE-2019-25013" } ] }, "sources": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#", "data": { "@container": "@list" } }, "data": [ { "db": "VULMON", "id": "CVE-2019-25013" }, { "db": "JVNDB", "id": "JVNDB-2019-016179" }, { "db": "PACKETSTORM", "id": "162634" }, { "db": "PACKETSTORM", "id": "162837" }, { "db": "PACKETSTORM", "id": "163257" }, { "db": "PACKETSTORM", "id": "163496" }, { "db": "PACKETSTORM", "id": "162877" }, { "db": "PACKETSTORM", "id": "163747" }, { "db": "PACKETSTORM", "id": "168011" }, { "db": "CNNVD", "id": "CNNVD-202101-048" }, { "db": "NVD", "id": "CVE-2019-25013" } ] }, "sources_release_date": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources_release_date#", "data": { "@container": "@list" } }, "data": [ { "date": "2021-01-04T00:00:00", "db": "VULMON", "id": "CVE-2019-25013" }, { "date": "2021-09-10T00:00:00", "db": "JVNDB", "id": "JVNDB-2019-016179" }, { "date": "2021-05-19T13:59:56", "db": "PACKETSTORM", "id": "162634" }, { "date": "2021-05-27T13:28:54", "db": "PACKETSTORM", "id": "162837" }, { "date": "2021-06-23T15:44:15", "db": "PACKETSTORM", "id": "163257" }, { "date": "2021-07-14T15:02:07", "db": "PACKETSTORM", "id": "163496" }, { "date": "2021-06-01T14:45:29", "db": "PACKETSTORM", "id": "162877" }, { "date": "2021-08-06T14:02:37", "db": "PACKETSTORM", "id": "163747" }, { "date": "2022-08-09T14:36:05", "db": "PACKETSTORM", "id": "168011" }, { "date": "2021-01-04T00:00:00", "db": "CNNVD", "id": "CNNVD-202101-048" }, { "date": "2021-01-04T18:15:13.027000", "db": "NVD", "id": "CVE-2019-25013" } ] }, "sources_update_date": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources_update_date#", "data": { "@container": "@list" } }, "data": [ { "date": "2023-11-09T00:00:00", "db": "VULMON", "id": "CVE-2019-25013" }, { "date": "2023-06-16T05:32:00", "db": "JVNDB", "id": "JVNDB-2019-016179" }, { "date": "2022-12-12T00:00:00", "db": "CNNVD", "id": "CNNVD-202101-048" }, { "date": "2023-11-09T14:44:33.733000", "db": "NVD", "id": "CVE-2019-25013" } ] }, "threat_type": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/threat_type#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "remote", "sources": [ { "db": "PACKETSTORM", "id": "168011" }, { "db": "CNNVD", "id": "CNNVD-202101-048" } ], "trust": 0.7 }, "title": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/title#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "GNU\u00a0C\u00a0Library\u00a0 Out-of-bounds read vulnerability in", "sources": [ { "db": "JVNDB", "id": "JVNDB-2019-016179" } ], "trust": 0.8 }, "type": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/type#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "buffer error", "sources": [ { "db": "CNNVD", "id": "CNNVD-202101-048" } ], "trust": 0.6 } }
var-201706-0334
Vulnerability from variot
glibc contains a vulnerability that allows specially crafted LD_LIBRARY_PATH values to manipulate the heap/stack, causing them to alias, potentially resulting in arbitrary code execution. Please note that additional hardening changes have been made to glibc to prevent manipulation of stack and heap memory but these issues are not directly exploitable, as such they have not been given a CVE. This affects glibc 2.25 and earlier. glibc Contains a buffer error vulnerability.Information is obtained, information is altered, and service operation is disrupted (DoS) There is a possibility of being put into a state. glibc (also known as GNU C Library, libc6) is an open source and free C language compiler released under the LGPL license agreement. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
===================================================================== Red Hat Security Advisory
Synopsis: Important: glibc security update Advisory ID: RHSA-2017:1479-01 Product: Red Hat Enterprise Linux Advisory URL: https://access.redhat.com/errata/RHSA-2017:1479 Issue date: 2017-06-19 CVE Names: CVE-2017-1000366 =====================================================================
- Summary:
An update for glibc is now available for Red Hat Enterprise Linux 5 Extended Lifecycle Support, Red Hat Enterprise Linux 5.9 Long Life, Red Hat Enterprise Linux 6.2 Advanced Update Support, Red Hat Enterprise Linux 6.4 Advanced Update Support, Red Hat Enterprise Linux 6.5 Advanced Update Support, Red Hat Enterprise Linux 6.5 Telco Extended Update Support, Red Hat Enterprise Linux 6.6 Advanced Update Support, Red Hat Enterprise Linux 6.6 Telco Extended Update Support, Red Hat Enterprise Linux 6.7 Extended Update Support, and Red Hat Enterprise Linux 7.2 Extended Update Support.
Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.
- Relevant releases/architectures:
Red Hat Enterprise Linux ComputeNode EUS (v. 7.2) - x86_64 Red Hat Enterprise Linux ComputeNode Optional EUS (v. 7.2) - x86_64 Red Hat Enterprise Linux HPC Node EUS (v. 6.7) - x86_64 Red Hat Enterprise Linux HPC Node Optional EUS (v. 6.7) - x86_64 Red Hat Enterprise Linux Long Life (v. 5.9 server) - i386, ia64, x86_64 Red Hat Enterprise Linux Server (v. 5 ELS) - i386, s390x, x86_64 Red Hat Enterprise Linux Server AUS (v. 6.2) - x86_64 Red Hat Enterprise Linux Server AUS (v. 6.4) - x86_64 Red Hat Enterprise Linux Server AUS (v. 6.5) - x86_64 Red Hat Enterprise Linux Server AUS (v. 6.6) - x86_64 Red Hat Enterprise Linux Server EUS (v. 6.7) - i386, ppc64, s390x, x86_64 Red Hat Enterprise Linux Server EUS (v. 7.2) - ppc64, ppc64le, s390x, x86_64 Red Hat Enterprise Linux Server Optional AUS (v. 6.2) - x86_64 Red Hat Enterprise Linux Server Optional AUS (v. 6.4) - x86_64 Red Hat Enterprise Linux Server Optional AUS (v. 6.5) - x86_64 Red Hat Enterprise Linux Server Optional AUS (v. 6.6) - x86_64 Red Hat Enterprise Linux Server Optional EUS (v. 6.7) - i386, ppc64, s390x, x86_64 Red Hat Enterprise Linux Server Optional EUS (v. 7.2) - ppc64, ppc64le, s390x, x86_64 Red Hat Enterprise Linux Server Optional TUS (v. 6.5) - x86_64 Red Hat Enterprise Linux Server Optional TUS (v. 6.6) - x86_64 Red Hat Enterprise Linux Server TUS (v. 6.5) - x86_64 Red Hat Enterprise Linux Server TUS (v. 6.6) - x86_64
- Description:
The glibc packages provide the standard C libraries (libc), POSIX thread libraries (libpthread), standard math libraries (libm), and the name service cache daemon (nscd) used by multiple programs on the system. Without these libraries, the Linux system cannot function correctly. This is glibc-side mitigation which blocks processing of LD_LIBRARY_PATH for programs running in secure-execution mode and reduces the number of allocations performed by the processing of LD_AUDIT, LD_PRELOAD, and LD_HWCAP_MASK, making successful exploitation of this issue more difficult. (CVE-2017-1000366)
Red Hat would like to thank Qualys Research Labs for reporting this issue.
- Solution:
For details on how to apply this update, which includes the changes described in this advisory, refer to:
https://access.redhat.com/articles/11258
For the update to take effect, all services linked to the glibc library must be restarted, or the system rebooted.
- Bugs fixed (https://bugzilla.redhat.com/):
1452543 - CVE-2017-1000366 glibc: heap/stack gap jumping via unbounded stack allocations
- Package List:
Red Hat Enterprise Linux Long Life (v. 5.9 server):
Source: glibc-2.5-107.el5_9.9.src.rpm
i386: glibc-2.5-107.el5_9.9.i386.rpm glibc-2.5-107.el5_9.9.i686.rpm glibc-common-2.5-107.el5_9.9.i386.rpm glibc-debuginfo-2.5-107.el5_9.9.i386.rpm glibc-debuginfo-2.5-107.el5_9.9.i686.rpm glibc-debuginfo-common-2.5-107.el5_9.9.i386.rpm glibc-devel-2.5-107.el5_9.9.i386.rpm glibc-headers-2.5-107.el5_9.9.i386.rpm glibc-utils-2.5-107.el5_9.9.i386.rpm nscd-2.5-107.el5_9.9.i386.rpm
ia64: glibc-2.5-107.el5_9.9.i686.rpm glibc-2.5-107.el5_9.9.ia64.rpm glibc-common-2.5-107.el5_9.9.ia64.rpm glibc-debuginfo-2.5-107.el5_9.9.i686.rpm glibc-debuginfo-2.5-107.el5_9.9.ia64.rpm glibc-debuginfo-common-2.5-107.el5_9.9.i386.rpm glibc-devel-2.5-107.el5_9.9.ia64.rpm glibc-headers-2.5-107.el5_9.9.ia64.rpm glibc-utils-2.5-107.el5_9.9.ia64.rpm nscd-2.5-107.el5_9.9.ia64.rpm
x86_64: glibc-2.5-107.el5_9.9.i686.rpm glibc-2.5-107.el5_9.9.x86_64.rpm glibc-common-2.5-107.el5_9.9.x86_64.rpm glibc-debuginfo-2.5-107.el5_9.9.i386.rpm glibc-debuginfo-2.5-107.el5_9.9.i686.rpm glibc-debuginfo-2.5-107.el5_9.9.x86_64.rpm glibc-debuginfo-common-2.5-107.el5_9.9.i386.rpm glibc-devel-2.5-107.el5_9.9.i386.rpm glibc-devel-2.5-107.el5_9.9.x86_64.rpm glibc-headers-2.5-107.el5_9.9.x86_64.rpm glibc-utils-2.5-107.el5_9.9.x86_64.rpm nscd-2.5-107.el5_9.9.x86_64.rpm
Red Hat Enterprise Linux Server (v. 5 ELS):
Source: glibc-2.5-123.el5_11.4.src.rpm
i386: glibc-2.5-123.el5_11.4.i386.rpm glibc-2.5-123.el5_11.4.i686.rpm glibc-common-2.5-123.el5_11.4.i386.rpm glibc-debuginfo-2.5-123.el5_11.4.i386.rpm glibc-debuginfo-2.5-123.el5_11.4.i686.rpm glibc-debuginfo-common-2.5-123.el5_11.4.i386.rpm glibc-devel-2.5-123.el5_11.4.i386.rpm glibc-headers-2.5-123.el5_11.4.i386.rpm glibc-utils-2.5-123.el5_11.4.i386.rpm nscd-2.5-123.el5_11.4.i386.rpm
s390x: glibc-2.5-123.el5_11.4.s390.rpm glibc-2.5-123.el5_11.4.s390x.rpm glibc-common-2.5-123.el5_11.4.s390x.rpm glibc-debuginfo-2.5-123.el5_11.4.s390.rpm glibc-debuginfo-2.5-123.el5_11.4.s390x.rpm glibc-devel-2.5-123.el5_11.4.s390.rpm glibc-devel-2.5-123.el5_11.4.s390x.rpm glibc-headers-2.5-123.el5_11.4.s390x.rpm glibc-utils-2.5-123.el5_11.4.s390x.rpm nscd-2.5-123.el5_11.4.s390x.rpm
x86_64: glibc-2.5-123.el5_11.4.i686.rpm glibc-2.5-123.el5_11.4.x86_64.rpm glibc-common-2.5-123.el5_11.4.x86_64.rpm glibc-debuginfo-2.5-123.el5_11.4.i386.rpm glibc-debuginfo-2.5-123.el5_11.4.i686.rpm glibc-debuginfo-2.5-123.el5_11.4.x86_64.rpm glibc-debuginfo-common-2.5-123.el5_11.4.i386.rpm glibc-devel-2.5-123.el5_11.4.i386.rpm glibc-devel-2.5-123.el5_11.4.x86_64.rpm glibc-headers-2.5-123.el5_11.4.x86_64.rpm glibc-utils-2.5-123.el5_11.4.x86_64.rpm nscd-2.5-123.el5_11.4.x86_64.rpm
Red Hat Enterprise Linux HPC Node EUS (v. 6.7):
Source: glibc-2.12-1.166.el6_7.8.src.rpm
x86_64: glibc-2.12-1.166.el6_7.8.i686.rpm glibc-2.12-1.166.el6_7.8.x86_64.rpm glibc-common-2.12-1.166.el6_7.8.x86_64.rpm glibc-debuginfo-2.12-1.166.el6_7.8.i686.rpm glibc-debuginfo-2.12-1.166.el6_7.8.x86_64.rpm glibc-debuginfo-common-2.12-1.166.el6_7.8.i686.rpm glibc-debuginfo-common-2.12-1.166.el6_7.8.x86_64.rpm glibc-devel-2.12-1.166.el6_7.8.i686.rpm glibc-devel-2.12-1.166.el6_7.8.x86_64.rpm glibc-headers-2.12-1.166.el6_7.8.x86_64.rpm glibc-utils-2.12-1.166.el6_7.8.x86_64.rpm nscd-2.12-1.166.el6_7.8.x86_64.rpm
Red Hat Enterprise Linux HPC Node Optional EUS (v. 6.7):
x86_64: glibc-debuginfo-2.12-1.166.el6_7.8.i686.rpm glibc-debuginfo-2.12-1.166.el6_7.8.x86_64.rpm glibc-debuginfo-common-2.12-1.166.el6_7.8.i686.rpm glibc-debuginfo-common-2.12-1.166.el6_7.8.x86_64.rpm glibc-static-2.12-1.166.el6_7.8.i686.rpm glibc-static-2.12-1.166.el6_7.8.x86_64.rpm
Red Hat Enterprise Linux Server AUS (v. 6.2):
Source: glibc-2.12-1.47.el6_2.18.src.rpm
x86_64: glibc-2.12-1.47.el6_2.18.i686.rpm glibc-2.12-1.47.el6_2.18.x86_64.rpm glibc-common-2.12-1.47.el6_2.18.x86_64.rpm glibc-debuginfo-2.12-1.47.el6_2.18.i686.rpm glibc-debuginfo-2.12-1.47.el6_2.18.x86_64.rpm glibc-debuginfo-common-2.12-1.47.el6_2.18.i686.rpm glibc-debuginfo-common-2.12-1.47.el6_2.18.x86_64.rpm glibc-devel-2.12-1.47.el6_2.18.i686.rpm glibc-devel-2.12-1.47.el6_2.18.x86_64.rpm glibc-headers-2.12-1.47.el6_2.18.x86_64.rpm glibc-utils-2.12-1.47.el6_2.18.x86_64.rpm nscd-2.12-1.47.el6_2.18.x86_64.rpm
Red Hat Enterprise Linux Server AUS (v. 6.4):
Source: glibc-2.12-1.107.el6_4.10.src.rpm
x86_64: glibc-2.12-1.107.el6_4.10.i686.rpm glibc-2.12-1.107.el6_4.10.x86_64.rpm glibc-common-2.12-1.107.el6_4.10.x86_64.rpm glibc-debuginfo-2.12-1.107.el6_4.10.i686.rpm glibc-debuginfo-2.12-1.107.el6_4.10.x86_64.rpm glibc-debuginfo-common-2.12-1.107.el6_4.10.i686.rpm glibc-debuginfo-common-2.12-1.107.el6_4.10.x86_64.rpm glibc-devel-2.12-1.107.el6_4.10.i686.rpm glibc-devel-2.12-1.107.el6_4.10.x86_64.rpm glibc-headers-2.12-1.107.el6_4.10.x86_64.rpm glibc-utils-2.12-1.107.el6_4.10.x86_64.rpm nscd-2.12-1.107.el6_4.10.x86_64.rpm
Red Hat Enterprise Linux Server AUS (v. 6.5):
Source: glibc-2.12-1.132.el6_5.9.src.rpm
x86_64: glibc-2.12-1.132.el6_5.9.i686.rpm glibc-2.12-1.132.el6_5.9.x86_64.rpm glibc-common-2.12-1.132.el6_5.9.x86_64.rpm glibc-debuginfo-2.12-1.132.el6_5.9.i686.rpm glibc-debuginfo-2.12-1.132.el6_5.9.x86_64.rpm glibc-debuginfo-common-2.12-1.132.el6_5.9.i686.rpm glibc-debuginfo-common-2.12-1.132.el6_5.9.x86_64.rpm glibc-devel-2.12-1.132.el6_5.9.i686.rpm glibc-devel-2.12-1.132.el6_5.9.x86_64.rpm glibc-headers-2.12-1.132.el6_5.9.x86_64.rpm glibc-utils-2.12-1.132.el6_5.9.x86_64.rpm nscd-2.12-1.132.el6_5.9.x86_64.rpm
Red Hat Enterprise Linux Server TUS (v. 6.5):
Source: glibc-2.12-1.132.el6_5.9.src.rpm
x86_64: glibc-2.12-1.132.el6_5.9.i686.rpm glibc-2.12-1.132.el6_5.9.x86_64.rpm glibc-common-2.12-1.132.el6_5.9.x86_64.rpm glibc-debuginfo-2.12-1.132.el6_5.9.i686.rpm glibc-debuginfo-2.12-1.132.el6_5.9.x86_64.rpm glibc-debuginfo-common-2.12-1.132.el6_5.9.i686.rpm glibc-debuginfo-common-2.12-1.132.el6_5.9.x86_64.rpm glibc-devel-2.12-1.132.el6_5.9.i686.rpm glibc-devel-2.12-1.132.el6_5.9.x86_64.rpm glibc-headers-2.12-1.132.el6_5.9.x86_64.rpm glibc-utils-2.12-1.132.el6_5.9.x86_64.rpm nscd-2.12-1.132.el6_5.9.x86_64.rpm
Red Hat Enterprise Linux Server AUS (v. 6.6):
Source: glibc-2.12-1.149.el6_6.12.src.rpm
x86_64: glibc-2.12-1.149.el6_6.12.i686.rpm glibc-2.12-1.149.el6_6.12.x86_64.rpm glibc-common-2.12-1.149.el6_6.12.x86_64.rpm glibc-debuginfo-2.12-1.149.el6_6.12.i686.rpm glibc-debuginfo-2.12-1.149.el6_6.12.x86_64.rpm glibc-debuginfo-common-2.12-1.149.el6_6.12.i686.rpm glibc-debuginfo-common-2.12-1.149.el6_6.12.x86_64.rpm glibc-devel-2.12-1.149.el6_6.12.i686.rpm glibc-devel-2.12-1.149.el6_6.12.x86_64.rpm glibc-headers-2.12-1.149.el6_6.12.x86_64.rpm glibc-utils-2.12-1.149.el6_6.12.x86_64.rpm nscd-2.12-1.149.el6_6.12.x86_64.rpm
Red Hat Enterprise Linux Server TUS (v. 6.6):
Source: glibc-2.12-1.149.el6_6.12.src.rpm
x86_64: glibc-2.12-1.149.el6_6.12.i686.rpm glibc-2.12-1.149.el6_6.12.x86_64.rpm glibc-common-2.12-1.149.el6_6.12.x86_64.rpm glibc-debuginfo-2.12-1.149.el6_6.12.i686.rpm glibc-debuginfo-2.12-1.149.el6_6.12.x86_64.rpm glibc-debuginfo-common-2.12-1.149.el6_6.12.i686.rpm glibc-debuginfo-common-2.12-1.149.el6_6.12.x86_64.rpm glibc-devel-2.12-1.149.el6_6.12.i686.rpm glibc-devel-2.12-1.149.el6_6.12.x86_64.rpm glibc-headers-2.12-1.149.el6_6.12.x86_64.rpm glibc-utils-2.12-1.149.el6_6.12.x86_64.rpm nscd-2.12-1.149.el6_6.12.x86_64.rpm
Red Hat Enterprise Linux Server EUS (v. 6.7):
Source: glibc-2.12-1.166.el6_7.8.src.rpm
i386: glibc-2.12-1.166.el6_7.8.i686.rpm glibc-common-2.12-1.166.el6_7.8.i686.rpm glibc-debuginfo-2.12-1.166.el6_7.8.i686.rpm glibc-debuginfo-common-2.12-1.166.el6_7.8.i686.rpm glibc-devel-2.12-1.166.el6_7.8.i686.rpm glibc-headers-2.12-1.166.el6_7.8.i686.rpm glibc-utils-2.12-1.166.el6_7.8.i686.rpm nscd-2.12-1.166.el6_7.8.i686.rpm
ppc64: glibc-2.12-1.166.el6_7.8.ppc.rpm glibc-2.12-1.166.el6_7.8.ppc64.rpm glibc-common-2.12-1.166.el6_7.8.ppc64.rpm glibc-debuginfo-2.12-1.166.el6_7.8.ppc.rpm glibc-debuginfo-2.12-1.166.el6_7.8.ppc64.rpm glibc-debuginfo-common-2.12-1.166.el6_7.8.ppc.rpm glibc-debuginfo-common-2.12-1.166.el6_7.8.ppc64.rpm glibc-devel-2.12-1.166.el6_7.8.ppc.rpm glibc-devel-2.12-1.166.el6_7.8.ppc64.rpm glibc-headers-2.12-1.166.el6_7.8.ppc64.rpm glibc-utils-2.12-1.166.el6_7.8.ppc64.rpm nscd-2.12-1.166.el6_7.8.ppc64.rpm
s390x: glibc-2.12-1.166.el6_7.8.s390.rpm glibc-2.12-1.166.el6_7.8.s390x.rpm glibc-common-2.12-1.166.el6_7.8.s390x.rpm glibc-debuginfo-2.12-1.166.el6_7.8.s390.rpm glibc-debuginfo-2.12-1.166.el6_7.8.s390x.rpm glibc-debuginfo-common-2.12-1.166.el6_7.8.s390.rpm glibc-debuginfo-common-2.12-1.166.el6_7.8.s390x.rpm glibc-devel-2.12-1.166.el6_7.8.s390.rpm glibc-devel-2.12-1.166.el6_7.8.s390x.rpm glibc-headers-2.12-1.166.el6_7.8.s390x.rpm glibc-utils-2.12-1.166.el6_7.8.s390x.rpm nscd-2.12-1.166.el6_7.8.s390x.rpm
x86_64: glibc-2.12-1.166.el6_7.8.i686.rpm glibc-2.12-1.166.el6_7.8.x86_64.rpm glibc-common-2.12-1.166.el6_7.8.x86_64.rpm glibc-debuginfo-2.12-1.166.el6_7.8.i686.rpm glibc-debuginfo-2.12-1.166.el6_7.8.x86_64.rpm glibc-debuginfo-common-2.12-1.166.el6_7.8.i686.rpm glibc-debuginfo-common-2.12-1.166.el6_7.8.x86_64.rpm glibc-devel-2.12-1.166.el6_7.8.i686.rpm glibc-devel-2.12-1.166.el6_7.8.x86_64.rpm glibc-headers-2.12-1.166.el6_7.8.x86_64.rpm glibc-utils-2.12-1.166.el6_7.8.x86_64.rpm nscd-2.12-1.166.el6_7.8.x86_64.rpm
Red Hat Enterprise Linux Server Optional AUS (v. 6.2):
Source: glibc-2.12-1.47.el6_2.18.src.rpm
x86_64: glibc-debuginfo-2.12-1.47.el6_2.18.i686.rpm glibc-debuginfo-2.12-1.47.el6_2.18.x86_64.rpm glibc-debuginfo-common-2.12-1.47.el6_2.18.i686.rpm glibc-debuginfo-common-2.12-1.47.el6_2.18.x86_64.rpm glibc-static-2.12-1.47.el6_2.18.i686.rpm glibc-static-2.12-1.47.el6_2.18.x86_64.rpm
Red Hat Enterprise Linux Server Optional AUS (v. 6.4):
Source: glibc-2.12-1.107.el6_4.10.src.rpm
x86_64: glibc-debuginfo-2.12-1.107.el6_4.10.i686.rpm glibc-debuginfo-2.12-1.107.el6_4.10.x86_64.rpm glibc-debuginfo-common-2.12-1.107.el6_4.10.i686.rpm glibc-debuginfo-common-2.12-1.107.el6_4.10.x86_64.rpm glibc-static-2.12-1.107.el6_4.10.i686.rpm glibc-static-2.12-1.107.el6_4.10.x86_64.rpm
Red Hat Enterprise Linux Server Optional AUS (v. 6.5):
Source: glibc-2.12-1.132.el6_5.9.src.rpm
x86_64: glibc-debuginfo-2.12-1.132.el6_5.9.i686.rpm glibc-debuginfo-2.12-1.132.el6_5.9.x86_64.rpm glibc-debuginfo-common-2.12-1.132.el6_5.9.i686.rpm glibc-debuginfo-common-2.12-1.132.el6_5.9.x86_64.rpm glibc-static-2.12-1.132.el6_5.9.i686.rpm glibc-static-2.12-1.132.el6_5.9.x86_64.rpm
Red Hat Enterprise Linux Server Optional TUS (v. 6.5):
Source: glibc-2.12-1.132.el6_5.9.src.rpm
x86_64: glibc-debuginfo-2.12-1.132.el6_5.9.i686.rpm glibc-debuginfo-2.12-1.132.el6_5.9.x86_64.rpm glibc-debuginfo-common-2.12-1.132.el6_5.9.i686.rpm glibc-debuginfo-common-2.12-1.132.el6_5.9.x86_64.rpm glibc-static-2.12-1.132.el6_5.9.i686.rpm glibc-static-2.12-1.132.el6_5.9.x86_64.rpm
Red Hat Enterprise Linux Server Optional AUS (v. 6.6):
x86_64: glibc-debuginfo-2.12-1.149.el6_6.12.i686.rpm glibc-debuginfo-2.12-1.149.el6_6.12.x86_64.rpm glibc-debuginfo-common-2.12-1.149.el6_6.12.i686.rpm glibc-debuginfo-common-2.12-1.149.el6_6.12.x86_64.rpm glibc-static-2.12-1.149.el6_6.12.i686.rpm glibc-static-2.12-1.149.el6_6.12.x86_64.rpm
Red Hat Enterprise Linux Server Optional TUS (v. 6.6):
x86_64: glibc-debuginfo-2.12-1.149.el6_6.12.i686.rpm glibc-debuginfo-2.12-1.149.el6_6.12.x86_64.rpm glibc-debuginfo-common-2.12-1.149.el6_6.12.i686.rpm glibc-debuginfo-common-2.12-1.149.el6_6.12.x86_64.rpm glibc-static-2.12-1.149.el6_6.12.i686.rpm glibc-static-2.12-1.149.el6_6.12.x86_64.rpm
Red Hat Enterprise Linux Server Optional EUS (v. 6.7):
i386: glibc-debuginfo-2.12-1.166.el6_7.8.i686.rpm glibc-debuginfo-common-2.12-1.166.el6_7.8.i686.rpm glibc-static-2.12-1.166.el6_7.8.i686.rpm
ppc64: glibc-debuginfo-2.12-1.166.el6_7.8.ppc.rpm glibc-debuginfo-2.12-1.166.el6_7.8.ppc64.rpm glibc-debuginfo-common-2.12-1.166.el6_7.8.ppc.rpm glibc-debuginfo-common-2.12-1.166.el6_7.8.ppc64.rpm glibc-static-2.12-1.166.el6_7.8.ppc.rpm glibc-static-2.12-1.166.el6_7.8.ppc64.rpm
s390x: glibc-debuginfo-2.12-1.166.el6_7.8.s390.rpm glibc-debuginfo-2.12-1.166.el6_7.8.s390x.rpm glibc-debuginfo-common-2.12-1.166.el6_7.8.s390.rpm glibc-debuginfo-common-2.12-1.166.el6_7.8.s390x.rpm glibc-static-2.12-1.166.el6_7.8.s390.rpm glibc-static-2.12-1.166.el6_7.8.s390x.rpm
x86_64: glibc-debuginfo-2.12-1.166.el6_7.8.i686.rpm glibc-debuginfo-2.12-1.166.el6_7.8.x86_64.rpm glibc-debuginfo-common-2.12-1.166.el6_7.8.i686.rpm glibc-debuginfo-common-2.12-1.166.el6_7.8.x86_64.rpm glibc-static-2.12-1.166.el6_7.8.i686.rpm glibc-static-2.12-1.166.el6_7.8.x86_64.rpm
Red Hat Enterprise Linux ComputeNode EUS (v. 7.2):
Source: glibc-2.17-106.el7_2.9.src.rpm
x86_64: glibc-2.17-106.el7_2.9.i686.rpm glibc-2.17-106.el7_2.9.x86_64.rpm glibc-common-2.17-106.el7_2.9.x86_64.rpm glibc-debuginfo-2.17-106.el7_2.9.i686.rpm glibc-debuginfo-2.17-106.el7_2.9.x86_64.rpm glibc-debuginfo-common-2.17-106.el7_2.9.i686.rpm glibc-debuginfo-common-2.17-106.el7_2.9.x86_64.rpm glibc-devel-2.17-106.el7_2.9.i686.rpm glibc-devel-2.17-106.el7_2.9.x86_64.rpm glibc-headers-2.17-106.el7_2.9.x86_64.rpm glibc-utils-2.17-106.el7_2.9.x86_64.rpm nscd-2.17-106.el7_2.9.x86_64.rpm
Red Hat Enterprise Linux ComputeNode Optional EUS (v. 7.2):
x86_64: glibc-debuginfo-2.17-106.el7_2.9.i686.rpm glibc-debuginfo-2.17-106.el7_2.9.x86_64.rpm glibc-debuginfo-common-2.17-106.el7_2.9.i686.rpm glibc-debuginfo-common-2.17-106.el7_2.9.x86_64.rpm glibc-static-2.17-106.el7_2.9.i686.rpm glibc-static-2.17-106.el7_2.9.x86_64.rpm
Red Hat Enterprise Linux Server EUS (v. 7.2):
Source: glibc-2.17-106.el7_2.9.src.rpm
ppc64: glibc-2.17-106.el7_2.9.ppc.rpm glibc-2.17-106.el7_2.9.ppc64.rpm glibc-common-2.17-106.el7_2.9.ppc64.rpm glibc-debuginfo-2.17-106.el7_2.9.ppc.rpm glibc-debuginfo-2.17-106.el7_2.9.ppc64.rpm glibc-debuginfo-common-2.17-106.el7_2.9.ppc.rpm glibc-debuginfo-common-2.17-106.el7_2.9.ppc64.rpm glibc-devel-2.17-106.el7_2.9.ppc.rpm glibc-devel-2.17-106.el7_2.9.ppc64.rpm glibc-headers-2.17-106.el7_2.9.ppc64.rpm glibc-utils-2.17-106.el7_2.9.ppc64.rpm nscd-2.17-106.el7_2.9.ppc64.rpm
ppc64le: glibc-2.17-106.el7_2.9.ppc64le.rpm glibc-common-2.17-106.el7_2.9.ppc64le.rpm glibc-debuginfo-2.17-106.el7_2.9.ppc64le.rpm glibc-debuginfo-common-2.17-106.el7_2.9.ppc64le.rpm glibc-devel-2.17-106.el7_2.9.ppc64le.rpm glibc-headers-2.17-106.el7_2.9.ppc64le.rpm glibc-utils-2.17-106.el7_2.9.ppc64le.rpm nscd-2.17-106.el7_2.9.ppc64le.rpm
s390x: glibc-2.17-106.el7_2.9.s390.rpm glibc-2.17-106.el7_2.9.s390x.rpm glibc-common-2.17-106.el7_2.9.s390x.rpm glibc-debuginfo-2.17-106.el7_2.9.s390.rpm glibc-debuginfo-2.17-106.el7_2.9.s390x.rpm glibc-debuginfo-common-2.17-106.el7_2.9.s390.rpm glibc-debuginfo-common-2.17-106.el7_2.9.s390x.rpm glibc-devel-2.17-106.el7_2.9.s390.rpm glibc-devel-2.17-106.el7_2.9.s390x.rpm glibc-headers-2.17-106.el7_2.9.s390x.rpm glibc-utils-2.17-106.el7_2.9.s390x.rpm nscd-2.17-106.el7_2.9.s390x.rpm
x86_64: glibc-2.17-106.el7_2.9.i686.rpm glibc-2.17-106.el7_2.9.x86_64.rpm glibc-common-2.17-106.el7_2.9.x86_64.rpm glibc-debuginfo-2.17-106.el7_2.9.i686.rpm glibc-debuginfo-2.17-106.el7_2.9.x86_64.rpm glibc-debuginfo-common-2.17-106.el7_2.9.i686.rpm glibc-debuginfo-common-2.17-106.el7_2.9.x86_64.rpm glibc-devel-2.17-106.el7_2.9.i686.rpm glibc-devel-2.17-106.el7_2.9.x86_64.rpm glibc-headers-2.17-106.el7_2.9.x86_64.rpm glibc-utils-2.17-106.el7_2.9.x86_64.rpm nscd-2.17-106.el7_2.9.x86_64.rpm
Red Hat Enterprise Linux Server Optional EUS (v. 7.2):
ppc64: glibc-debuginfo-2.17-106.el7_2.9.ppc.rpm glibc-debuginfo-2.17-106.el7_2.9.ppc64.rpm glibc-debuginfo-common-2.17-106.el7_2.9.ppc.rpm glibc-debuginfo-common-2.17-106.el7_2.9.ppc64.rpm glibc-static-2.17-106.el7_2.9.ppc.rpm glibc-static-2.17-106.el7_2.9.ppc64.rpm
ppc64le: glibc-debuginfo-2.17-106.el7_2.9.ppc64le.rpm glibc-debuginfo-common-2.17-106.el7_2.9.ppc64le.rpm glibc-static-2.17-106.el7_2.9.ppc64le.rpm
s390x: glibc-debuginfo-2.17-106.el7_2.9.s390.rpm glibc-debuginfo-2.17-106.el7_2.9.s390x.rpm glibc-debuginfo-common-2.17-106.el7_2.9.s390.rpm glibc-debuginfo-common-2.17-106.el7_2.9.s390x.rpm glibc-static-2.17-106.el7_2.9.s390.rpm glibc-static-2.17-106.el7_2.9.s390x.rpm
x86_64: glibc-debuginfo-2.17-106.el7_2.9.i686.rpm glibc-debuginfo-2.17-106.el7_2.9.x86_64.rpm glibc-debuginfo-common-2.17-106.el7_2.9.i686.rpm glibc-debuginfo-common-2.17-106.el7_2.9.x86_64.rpm glibc-static-2.17-106.el7_2.9.i686.rpm glibc-static-2.17-106.el7_2.9.x86_64.rpm
These packages are GPG signed by Red Hat for security. Our key and details on how to verify the signature are available from https://access.redhat.com/security/team/key/
- References:
https://access.redhat.com/security/cve/CVE-2017-1000366 https://access.redhat.com/security/updates/classification/#important https://access.redhat.com/security/vulnerabilities/stackguard
- Contact:
The Red Hat security contact is secalert@redhat.com. More contact details at https://access.redhat.com/security/team/contact/
Copyright 2017 Red Hat, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iD8DBQFZSDV3XlSAg2UNWIIRAibeAKC2QtxViqngTTBVM9fvG1XjRCkgwACgrHP1 PVr1sUH9RUhxrQOKQqWtnKY= =ywUB -----END PGP SIGNATURE-----
-- RHSA-announce mailing list RHSA-announce@redhat.com https://www.redhat.com/mailman/listinfo/rhsa-announce . 6) - i386, x86_64
- For the full details, please refer to their advisory published at: https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
For the oldstable distribution (jessie), this problem has been fixed in version 2.19-18+deb8u10.
For the stable distribution (stretch), this problem has been fixed in version 2.24-11+deb9u1.
For the unstable distribution (sid), this problem will be fixed soon.
We recommend that you upgrade your glibc packages.
Gentoo Linux Security Advisory GLSA 201706-19
https://security.gentoo.org/
Severity: High Title: GNU C Library: Multiple vulnerabilities Date: June 20, 2017 Bugs: #608698, #608706, #622220 ID: 201706-19
Synopsis
Multiple vulnerabilities have been found in the GNU C Library, the worst of which may allow execution of arbitrary code.
Background
The GNU C library is the standard C library used by Gentoo Linux systems.
Impact
An attacker could possibly execute arbitrary code with the privileges of the process, escalate privileges or cause a Denial of Service condition.
Workaround
There is no known workaround at this time.
Resolution
All GNU C Library users should upgrade to the latest version:
# emerge --sync # emerge --ask --oneshot --verbose ">=sys-libs/glibc-2.23-r4"
References
[ 1 ] CVE-2015-5180 http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-5180 [ 2 ] CVE-2016-6323 http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-6323 [ 3 ] CVE-2017-1000366 http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-1000366 [ 4 ] Qualys Security Advisory - The Stack Clash https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
Availability
This GLSA and any updates to it are available for viewing at the Gentoo Security Website:
https://security.gentoo.org/glsa/201706-19
Concerns?
Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users' machines is of utmost importance to us. Any security concerns should be addressed to security@gentoo.org or alternatively, you may file a bug at https://bugs.gentoo.org.
License
Copyright 2017 Gentoo Foundation, Inc; referenced text belongs to its owner(s).
The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license.
http://creativecommons.org/licenses/by-sa/2.5
--cxbO5eT2swQBqr8k9tc6wcfapgLAJb4xR--
. Qualys Security Advisory
The Stack Clash
======================================================================== Contents ========================================================================
I. Introduction II. Problem II.1. Automatic stack expansion II.2. Stack guard-page II.3. Stack-clash exploitation III. Solutions IV. Results IV.1. Linux IV.2. OpenBSD IV.3. NetBSD IV.4. FreeBSD IV.5. Solaris V. Acknowledgments
======================================================================== I. Introduction ========================================================================
Our research started with a 96-megabyte surprise:
b97bb000-b97dc000 rw-p 00000000 00:00 0 [heap] bf7c6000-bf806000 rw-p 00000000 00:00 0 [stack]
and a 12-year-old question: "If the heap grows up, and the stack grows down, what happens when they clash? Is it exploitable? How?"
- In 2005, Gael Delalleau presented "Large memory management vulnerabilities" and the first stack-clash exploit in user-space (against mod_php 4.3.0 on Apache 2.0.53):
http://cansecwest.com/core05/memory_vulns_delalleau.pdf
- In 2010, Rafal Wojtczuk published "Exploiting large memory management vulnerabilities in Xorg server running on Linux", the second stack-clash exploit in user-space (CVE-2010-2240):
http://www.invisiblethingslab.com/resources/misc-2010/xorg-large-memory-attacks.pdf
- Since 2010, security researchers have exploited several stack-clashes in the kernel-space; for example:
https://jon.oberheide.org/blog/2010/11/29/exploiting-stack-overflows-in-the-linux-kernel/ https://jon.oberheide.org/files/infiltrate12-thestackisback.pdf https://googleprojectzero.blogspot.com/2016/06/exploiting-recursion-in-linux-kernel_20.html
In user-space, however, this problem has been greatly underestimated; the only public exploits are Gael Delalleau's and Rafal Wojtczuk's, and they were written before Linux introduced a protection against stack-clashes (a "guard-page" mapped below the stack):
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-2240
In this advisory, we show that stack-clashes are widespread in user-space, and exploitable despite the stack guard-page; we discovered multiple vulnerabilities in guard-page implementations, and devised general methods for:
-
"Clashing" the stack with another memory region: we allocate memory until the stack reaches another memory region, or until another memory region reaches the stack;
-
"Jumping" over the stack guard-page: we move the stack-pointer from the stack and into the other memory region, without accessing the stack guard-page;
-
"Smashing" the stack, or the other memory region: we overwrite the stack with the other memory region, or the other memory region with the stack.
To illustrate our findings, we developed the following exploits and proofs-of-concepts:
-
a local-root exploit against Exim (CVE-2017-1000369, CVE-2017-1000376) on i386 Debian;
-
a local-root exploit against Sudo (CVE-2017-1000367, CVE-2017-1000366) on i386 Debian, Ubuntu, CentOS;
-
an independent Sudoer-to-root exploit against CVE-2017-1000367 on any SELinux-enabled distribution;
-
a local-root exploit against ld.so and most SUID-root binaries (CVE-2017-1000366, CVE-2017-1000370) on i386 Debian, Fedora, CentOS;
-
a local-root exploit against ld.so and most SUID-root PIEs (CVE-2017-1000366, CVE-2017-1000371) on i386 Debian, Ubuntu, Fedora;
-
a local-root exploit against /bin/su (CVE-2017-1000366, CVE-2017-1000365) on i386 Debian;
-
a proof-of-concept that gains eip control against Sudo on i386 grsecurity/PaX (CVE-2017-1000367, CVE-2017-1000366, CVE-2017-1000377);
-
a local proof-of-concept that gains rip control against Exim (CVE-2017-1000369) on amd64 Debian;
-
a local-root exploit against ld.so and most SUID-root binaries (CVE-2017-1000366, CVE-2017-1000379) on amd64 Debian, Ubuntu, Fedora, CentOS;
-
a proof-of-concept against /usr/bin/at on i386 OpenBSD, for CVE-2017-1000372 in OpenBSD's stack guard-page implementation and CVE-2017-1000373 in OpenBSD's qsort() function;
-
a proof-of-concept for CVE-2017-1000374 and CVE-2017-1000375 in NetBSD's stack guard-page implementation;
-
a proof-of-concept for CVE-2017-1085 in FreeBSD's setrlimit() RLIMIT_STACK implementation;
-
two proofs-of-concept for CVE-2017-1083 and CVE-2017-1084 in FreeBSD's stack guard-page implementation;
-
a local-root exploit against /usr/bin/rsh (CVE-2017-3630, CVE-2017-3629, CVE-2017-3631) on Solaris 11.
======================================================================== II. Problem ========================================================================
Note: in this advisory, the "start of the stack" is the lowest address of its memory region, and the "end of the stack" is the highest address of its memory region; we do not use the ambiguous terms "top of the stack" and "bottom of the stack".
======================================================================== II.1. Automatic stack expansion ========================================================================
The user-space stack of a process is automatically expanded by the kernel:
-
if the stack-pointer (the esp register, on i386) reaches the start of the stack and the unmapped memory pages below (the stack grows down, on i386),
-
then a "page-fault" exception is raised and caught by the kernel,
-
and the page-fault handler transparently expands the user-space stack of the process (it decreases the start address of the stack),
-
or it terminates the process with a SIGSEGV if the stack expansion fails (for example, if the RLIMIT_STACK is reached).
Unfortunately, this stack expansion mechanism is implicit and fragile: it relies on page-fault exceptions, but if another memory region is mapped directly below the stack, then the stack-pointer can move from the stack into the other memory region without raising a page-fault, and:
-
the kernel cannot tell that the process needed more stack memory;
-
the process cannot tell that its stack-pointer moved from the stack into another memory region.
In contrast, the heap expansion mechanism is explicit and robust: the process uses the brk() system-call to tell the kernel that it needs more heap memory, and the kernel expands the heap accordingly (it increases the end address of the heap memory region -- the heap always grows up).
======================================================================== II.2. Stack guard-page ========================================================================
The fragile stack expansion mechanism poses a security threat: if the stack-pointer of a process can move from the stack into another memory region (which ends exactly where the stack starts) without raising a page-fault, then:
-
the process uses this other memory region as if it were an extension of the stack;
-
a write to this stack extension smashes the other memory region;
-
a write to the other memory region smashes the stack extension.
To protect against this security threat, the kernel maps a "guard-page" below the start of the stack: one or more PROT_NONE pages (or unmappable pages) that:
-
raise a page-fault exception if accessed (before the stack-pointer can move from the stack into another memory region);
-
terminate the process with a SIGSEGV (because the page-fault handler cannot expand the stack if another memory region is mapped directly below).
Unfortunately, a stack guard-page of a few kilobytes is insufficient (CVE-2017-1000364): if the stack-pointer "jumps" over the guard-page -- if it moves from the stack into another memory region without accessing the guard-page -- then no page-fault exception is raised and the stack extends into the other memory region.
This theoretical vulnerability was first described in Gael Delalleau's 2005 presentation (slides 24-29). In the present advisory, we discuss its practicalities, and multiple vulnerabilities in stack guard-page implementations (in OpenBSD, NetBSD, and FreeBSD), but we exclude related vulnerabilities such as unbounded alloca()s and VLAs (Variable-Length Arrays) that have been exploited in the past:
http://phrack.org/issues/63/14.html http://blog.exodusintel.com/2013/01/07/who-was-phone/
======================================================================== II.3. Stack-clash exploitation ========================================================================
Must be a clash, there's no alternative.
--The Clash, "Kingston Advice"
Our exploits follow a series of four sequential steps -- each step allocates memory that must not be freed before all steps are complete:
Step 1: Clash (the stack with another memory region) Step 2: Run (move the stack-pointer to the start of the stack) Step 3: Jump (over the stack guard-page, into the other memory region) Step 4: Smash (the stack, or the other memory region)
======================================================================== II.3.1. Step 1: Clash the stack with another memory region ========================================================================
Have the boys found the leak yet?
--The Clash, "The Leader"
Allocate memory until the start of the stack reaches the end of another memory region, or until the end of another memory region reaches the start of the stack.
-
The other memory region can be, for example: . the heap; . an anonymous mmap(); . the read-write segment of ld.so; . the read-write segment of a PIE, a Position-Independent Executable.
-
The memory allocated in this Step 1 can be, for example: . stack and heap memory; . stack and anonymous mmap() memory; . stack memory only.
-
The heap and anonymous mmap() memory can be:
. temporarily allocated, but not freed before the stack guard-page is jumped over in Step 3 and memory is smashed in Step 4;
. permanently leaked. On Linux, a general method for allocating anonymous mmap()s is the LD_AUDIT memory leak that we discovered in the ld.so part of the glibc, the GNU C Library (CVE-2017-1000366).
- The stack memory can be allocated, for example:
. through megabytes of command-line arguments and environment variables.
On Linux, this general method for allocating stack memory is limited
by the kernel to 1/4 of the current RLIMIT_STACK (1GB on i386 if
RLIMIT_STACK is RLIM_INFINITY -- man execve, "Limits on size of
arguments and environment").
However, as we were drafting this advisory, we realized that the
kernel imposes this limit on the argument and environment strings,
but not on the argv[] and envp[] pointers to these strings, and we
developed alternative versions of our Linux exploits that do not
depend on application-specific memory leaks (CVE-2017-1000365). through recursive function calls.
On BSD, we discovered a general method for allocating megabytes of
stack memory: a vulnerability in qsort() that causes this function
to recurse N/4 times, given a pathological input array of N elements
(CVE-2017-1000373 in OpenBSD, CVE-2017-1000378 in NetBSD, and
CVE-2017-1082 in FreeBSD).
- In a few rare cases, Step 1 is not needed, because another memory region is naturally mapped directly below the stack (for example, ld.so in our Solaris exploit).
======================================================================== II.3.2. Step 2: Move the stack-pointer to the start of the stack ========================================================================
Run, run, run, run, run, don't you know?
--The Clash, "Three Card Trick"
Consume the unused stack memory that separates the stack-pointer from the start of the stack. This Step 2 is similar to Step 3 ("Jump over the stack guard-page") but is needed because:
- the stack-pointer is usually several kilobytes higher than the start of the stack (functions that allocate a large stack-frame decrease the start address of the stack, but this address is never increased again); moreover:
. the FreeBSD kernel automatically expands the user-space stack of a process by multiples of 128KB (SGROWSIZ, in vm_map_growstack());
. the Linux kernel initially expands the user-space stack of a process by 128KB (stack_expand, in setup_arg_pages()).
- in Step 3, the stack-based buffer used to jump over the guard-page:
. is usually not large enough to simultaneously move the stack-pointer to the start of the stack, and then into another memory region;
. must not be fully written to (a full write would access the stack guard-page and terminate the process) but the stack memory consumed in this Step 2 can be fully written to (for example, strdupa() can be used in Step 2, but not in Step 3).
The stack memory consumed in this Step 2 can be, for example:
-
large stack-frames, alloca()s, or VLAs (which can be detected by grsecurity/PaX's STACKLEAK plugin for GCC, https://grsecurity.net/features.php);
-
recursive function calls (which can be detected by GNU cflow, http://www.gnu.org/software/cflow/);
-
on Linux, we discovered that the argv[] and envp[] arrays of pointers can be used to consume the 128KB of initial stack expansion, because the kernel allocates these arrays on the stack long after the call to setup_arg_pages(); this general method for completing Step 2 is exploitable locally, but the initial stack expansion poses a major obstacle to the remote exploitation of stack-clashes, as mentioned in IV.1.1.
In a few rare cases, Step 2 is not needed, because the stack-pointer is naturally close to the start of the stack (for example, in Exim's main() function, the 256KB group_list[] moves the stack-pointer to the start of the stack and beyond).
======================================================================== II.3.3. Step 3: Jump over the stack guard-page, into another memory region ========================================================================
You need a little jump of electrical shockers.
--The Clash, "Clash City Rockers"
Move the stack-pointer from the stack and into the memory region that clashed with the stack in Step 1, but without accessing the guard-page. To complete this Step 3, a large stack-based buffer, alloca(), or VLA is needed, and:
-
it must be larger than the guard-page;
-
it must end in the stack, above the guard-page;
-
it must start in the memory region below the stack guard-page;
-
it must not be fully written to (a full write would access the guard-page, raise a page-fault exception, and terminate the process, because the memory region mapped directly below the stack prevents the page-fault handler from expanding the stack).
In a few cases, Step 3 is not needed:
-
on FreeBSD, a stack guard-page is implemented but disabled by default (CVE-2017-1083);
-
on OpenBSD, NetBSD, and FreeBSD, we discovered implementation vulnerabilities that eliminate the stack guard-page (CVE-2017-1000372, CVE-2017-1000374, CVE-2017-1084).
On Linux, we devised general methods for jumping over the stack guard-page (CVE-2017-1000366):
- The glibc's __dcigettext() function alloca()tes single_locale, a stack-based buffer of up to 128KB (MAX_ARG_STRLEN, man execve), the length of the LANGUAGE environment variable (if the current locale is neither "C" nor "POSIX", but distributions install default locales such as "C.UTF-8" and "en_US.utf8").
If LANGUAGE is mostly composed of ':' characters, then single_locale is barely written to, and can be used to jump over the stack guard-page.
Moreover, if __dcigettext() finds the message to be translated, then _nl_find_msg() strdup()licates the OUTPUT_CHARSET environment variable and allows a local attacker to immediately smash the stack and gain control of the instruction pointer (the eip register, on i386), as detailed in Step 4a.
We exploited this stack-clash against Sudo and su, but most of the SUID (set-user-ID) and SGID (set-group-ID) binaries that call setlocale(LC_ALL, "") and __dcigettext() or its derivatives (the *gettext() functions, the _() convenience macro, the strerror() function) are exploitable.
- The glibc's vfprintf() function (called by the *printf() family of functions) alloca()tes a stack-based work buffer of up to 64KB (__MAX_ALLOCA_CUTOFF) if a width or precision is greater than 1KB (WORK_BUFFER_SIZE).
If the corresponding format specifier is %s then this work buffer is never written to and can be used to jump over the stack guard-page.
None of our exploits is based on this method, but it was one of our ideas to exploit Exim remotely, as mentioned in IV.1.1.
- The glibc's getaddrinfo() function calls gaih_inet(), which alloca()tes tmpbuf, a stack-based buffer of up to 64KB (__MAX_ALLOCA_CUTOFF) that may be used to jump over the stack guard-page.
Moreover, gaih_inet() calls the gethostbyname*() functions, which malloc()ate a heap-based DNS response of up to 64KB (MAXPACKET) that may allow a remote attacker to immediately smash the stack, as detailed in Step 4a.
None of our exploits is based on this method, but it may be the key to the remote exploitation of stack-clashes.
- The glibc's run-time dynamic linker ld.so alloca()tes llp_tmp, a stack-based copy of the LD_LIBRARY_PATH environment variable. If LD_LIBRARY_PATH contains Dynamic String Tokens (DSTs), they are first expanded: llp_tmp can be larger than 128KB (MAX_ARG_STRLEN) and not fully written to, and can therefore be used to jump over the stack guard-page and smash the memory region mapped directly below, as detailed in Step 4b.
We exploited this ld.so stack-clash in two data-only attacks that bypass NX (No-eXecute) and ASLR (Address Space Layout Randomization) and obtain a privileged shell through most SUID and SGID binaries on most i386 Linux distributions.
- Several local and remote applications allocate a 256KB stack-based "gid_t buffer[NGROUPS_MAX];" that is not fully written to and can be used to move the stack-pointer to the start of the stack (Step 2) and jump over the guard-page (Step 3). For example, Exim's main() function and older versions of util-linux's su.
None of our exploits is based on this method, but an experimental version of our Exim exploit unexpectedly gained control of eip after the group_list[] buffer had jumped over the stack guard-page.
======================================================================== II.3.4. Step 4: Either smash the stack with another memory region (Step 4a) or smash another memory region with the stack (Step 4b) ========================================================================
Smash and grab, it's that kind of world.
--The Clash, "One Emotion"
In Step 3, a function allocates a large stack-based buffer and jumps over the stack guard-page into the memory region mapped directly below; in Step 4, before this function returns and jumps back into the stack:
- Step 4a: a write to the memory region mapped below the stack (where esp still points to) effectively smashes the stack. We exploit this general method for completing Step 4 in Exim, Sudo, and su:
. we overwrite a return-address on the stack and gain control of eip;
. we return-into-libc (into system() or __libc_dlopen()) to defeat NX;
. we brute-force ASLR (8 bits of entropy) if CVE-2016-3672 is patched;
. we bypass SSP (Stack-Smashing Protector) because we overwrite the return-address of a function that is not protected by a stack canary (the memcpy() that smashes the stack usually overwrites its own stack-frame and return-address).
- Step 4b: a write to the stack effectively smashes the memory region mapped below (where esp still points to). This second method for completing Step 4 is application-specific (it depends on the contents of the memory region that we smash) unless we exploit the run-time dynamic linker ld.so:
. on Solaris, we devised a general method for smashing ld.so's read-write segment, overwriting one of its function pointers, and executing our own shell-code;
. on Linux, we exploited most SUID and SGID binaries through ld.so: our "hwcap" exploit smashes an mmap()ed string, and our ".dynamic" exploit smashes a PIE's read-write segment before it is mprotect()ed read-only by Full RELRO (Full RELocate Read-Only -- GNU_RELRO and BIND_NOW).
======================================================================== III. Solutions ========================================================================
Based on our research, we recommend that the affected operating systems:
- Increase the size of the stack guard-page to at least 1MB, and allow system administrators to easily modify this value (for example, grsecurity/PaX introduced /proc/sys/vm/heap_stack_gap in 2010).
This first, short-term solution is cheap, but it can be defeated by a very large stack-based buffer.
- Recompile all userland code (ld.so, libraries, binaries) with GCC's "-fstack-check" option, which prevents the stack-pointer from moving into another memory region without accessing the stack guard-page (it writes one word to every 4KB page allocated on the stack).
This second, long-term solution is expensive, but it cannot be defeated (even if the stack guard-page is only 4KB, one page) -- unless a vulnerability is discovered in the implementation of the stack guard-page or the "-fstack-check" option.
======================================================================== IV. Results ========================================================================
======================================================================== IV.1. Linux ========================================================================
======================================================================== IV.1.1. Exim ========================================================================
Debian 8.5
Crude exploitation
Our first exploit, a Local Privilege Escalation against Exim's SUID-root PIE (Position-Independent Executable) on i386 Debian 8.5, simply follows the four sequential steps outlined in II.3.
Step 1: Clash the stack with the heap
To reach the start of the stack with the end of the heap (man brk), we permanently leak memory through multiple -p command-line arguments that are malloc()ated by Exim but never free()d (CVE-2017-1000369) -- we call such a malloc()ated chunk of heap memory a "memleak-chunk".
Because the -p argument strings are originally allocated on the stack by execve(), we must cover half of the initial heap-stack distance (between the start of the heap and the end of the stack) with stack memory, and half of this distance with heap memory.
If we set the RLIMIT_STACK to 136MB (MIN_GAP, arch/x86/mm/mmap.c) then the initial heap-stack distance is minimal (randomized in a [96MB,137MB] range), but we cannot reach the stack with the heap because of the 1/4 limit imposed by the kernel on the argument and environment strings (man execve): 136MB/4=34MB of -p argument strings cannot cover 96MB/2=48MB, half of the minimum heap-stack distance.
Moreover, if we increase the RLIMIT_STACK, the initial heap-stack distance also increases and we still cannot reach the stack with the heap. However, if we set the RLIMIT_STACK to RLIM_INFINITY (4GB on i386) then the kernel switches from the default top-down mmap() layout to a legacy bottom-up mmap() layout, and:
-
the initial heap-stack distance is approximately 2GB, because the start of the heap (the initial brk()) is randomized above the address 0x40000000, and the end of the stack is randomized below the address 0xC0000000;
-
we can reach the stack with the heap, despite the 1/4 limit imposed by the kernel on the argument and environment strings, because 4GB/4=1GB of -p argument strings can cover 2GB/2=1GB, half of the initial heap-stack distance;
-
we clash the stack with the heap around the address 0x80000000.
Step 2: Move the stack-pointer (esp) to the start of the stack
The 256KB stack-based group_list[] in Exim's main() naturally consumes the 128KB of initial stack expansion, as mentioned in II.3.2.
Step 3: Jump over the stack guard-page and into the heap
To move esp from the start of the stack into the heap, without accessing the stack guard-page, we use a malformed -d command-line argument that is written to the 32KB (STRING_SPRINTF_BUFFER_SIZE) stack-based buffer in Exim's string_sprintf() function. This buffer is not fully written to and hence does not access the stack guard-page, because our -d argument string is much shorter than 32KB.
Step 4a: Smash the stack with the heap
Before string_sprintf() returns (and moves esp from the heap back into the stack) it calls string_copy(), which malloc()ates and memcpy()es our -d argument string to the end of the heap, where esp still points to -- we call this malloc()ated chunk of heap memory the "smashing-chunk".
This call to memcpy() therefore smashes its own stack-frame (which is not protected by SSP) with the contents of our smashing-chunk, and we overwrite memcpy()'s return-address with the address of libc's system() function (which is not randomized by ASLR because Debian 8.5 is vulnerable to CVE-2016-3672):
-
instead of smashing memcpy()'s stack-frame with an 8-byte pattern (the return-address to system() and its argument) we smash it with a simple 4-byte pattern (the return-address to system()), append "." to the PATH environment variable, and symlink() our exploit to the string that begins at the address of libc's system() function;
-
system() does not drop our escalated root privileges, because Debian's /bin/sh is dash, not bash and its -p option (man bash).
This first version of our Exim exploit obtained a root-shell after nearly a week of failed attempts; to improve this result, we analyzed every step of a successful run.
Refined exploitation
Step 1: Clash the stack with the heap
- The heap must be able to reach the stack [Condition 1]
The start of the heap is randomized in the 32MB range above the end of Exim's PIE (the end of its .bss section), but the growth of the heap is sometimes blocked by libraries that are mmap()ed within the same range (because of the legacy bottom-up mmap() layout). On Debian 8.5, Exim's libraries occupy about 8MB and thus block the growth of the heap with a probability of 8MB/32MB = 1/4.
When the heap is blocked by the libraries, malloc() switches from brk() to mmap()s of 1MB (MMAP_AS_MORECORE_SIZE), and our memory leak reaches the stack with mmap()s instead of the heap. Such a stack-clash is also exploitable, but its probability of success is low, as detailed in IV.1.6., and we therefore discarded this approach.
- The heap must always reach the stack, when not blocked by libraries
Because the initial heap-stack distance (between the start of the heap and the end of the stack) is a random variable:
-
either we allocate the exact amount of heap memory to cover the mean heap-stack distance, but the probability of success of this approach is low and we therefore discarded it;
-
or we allocate enough heap memory to always reach the stack, even when the initial heap-stack distance is maximal; after the heap reaches the stack, our memory leak allocates mmap()s of 1MB above the stack (below 0xC0000000) and below the heap (above the libraries), but it must not exhaust the address-space (the 1GB below 0x40000000 is unmappable);
-
the final heap-stack distance (between the end of the heap and the start of the stack) is also a random variable:
. its minimum value is 8KB (the stack guard-page, plus a safety page imposed by the brk() system-call in mm/mmap.c);
. its maximum value is roughly the size of a memleak-chunk, plus 128KB (DEFAULT_TOP_PAD, malloc/malloc.c).
Step 3: Jump over the stack guard-page and into the heap
-
The stack-pointer must jump over the guard-page and land into the free chunk at the end of the heap (the remainder of the heap after malloc() switches from brk() to mmap()), where both the smashing-chunk and memcpy()'s stack-frame are allocated and overwritten in Step 4a [Condition 2];
-
The write (of approximately smashing-chunk bytes) to string_sprintf()'s stack-based buffer (which starts where the guard-page jump lands) must not crash into the end of the heap [Condition 3].
Step 4a: Smash the stack with the heap
The smashing-chunk must be allocated into the free chunk at the end of the heap:
-
the smashing-chunk must not be allocated into the free chunks left over at the end of the 1MB mmap()s [Condition 4];
-
the memleak-chunks must not be allocated into the free chunk at the end of the heap [Condition 5].
Intuitively, the probability of gaining control of eip depends on the size of the smashing-chunk (the guard-page jump's landing-zone) and the size of the memleak-chunks (which determines the final heap-stack distance).
To maximize this probability, we wrote a helper program that imposes the following conditions on the smashing-chunk and memleak-chunks:
-
the smashing-chunk must be smaller than 32KB (STRING_SPRINTF_BUFFER_SIZE) [Condition 3];
-
the memleak-chunks must be smaller than 128KB (DEFAULT_MMAP_THRESHOLD, malloc/malloc.c);
-
the free chunk at the end of the heap must be larger than twice the smashing-chunk size [Conditions 2 and 3];
-
the free chunk at the end of the heap must be smaller than the memleak-chunk size [Condition 5];
-
when the final heap-stack distance is minimal, the 32KB (STRING_SPRINTF_BUFFER_SIZE) guard-page jump must land below the free chunk at the end of the heap [Condition 2];
-
the free chunks at the end of the 1MB mmap()s must be:
. either smaller than the smashing-chunk [Condition 4];
. or larger than the free chunk at the end of the heap (glibc's malloc() is a best-fit allocator) [Condition 4].
The resulting smashing-chunk and memleak-chunk sizes are:
smash: 10224 memleak: 27656 brk_min: 20464 brk_max: 24552 mmap_top: 25304 probability: 1/16 (0.06190487817)
In theory, the probability of gaining control of eip is 1/21: the product of the 1/16 probability calculated by this helper program (approximately (smashing-chunk / (memleak-chunk + DEFAULT_TOP_PAD))) and the 3/4 probability of reaching the stack with the heap [Condition 1].
In practice, on Debian 8.5, our final Exim exploit:
-
gains eip control in 1 run out of 28, on average;
-
takes 2.5 seconds per run (on a 4GB Virtual Machine);
-
has a good chance of obtaining a root-shell after 28*2.5 = 70 seconds;
-
uses 4GB of memory (2GB in the Exim process, and 2GB in the process fork()ed by system()).
Debian 8.6
Unlike Debian 8.5, Debian 8.6 is not vulnerable to CVE-2016-3672: after gaining eip control in Step 4a (Smash), the probability of successfully returning-into-libc's system() function is 1/256 (8 bits of entropy -- libraries are randomized in a 1MB range but aligned on 4KB).
Consequently, our final Exim exploit has a good chance of obtaining a root-shell on Debian 8.6 after 256282.5 seconds = 5 hours (256*28=7168 runs).
As we were drafting this advisory, we tried an alternative approach against Exim on Debian 8.6: we discovered that its stack is executable, because it depends on libgnutls-deb0, which depends on libp11-kit, which depends on libffi, which incorrectly requires an executable GNU_STACK (CVE-2017-1000376).
Initially, we discarded this approach because our 1GB of -p argument strings on the stack is not executable (_dl_make_stack_executable() only mprotect()s the stack below argv[] and envp[]):
41e00000-723d7000 rw-p 00000000 00:00 0 [heap] 802f1000-80334000 rwxp 00000000 00:00 0 [stack] 80334000-bfce6000 rw-p 00000000 00:00 0
and because the stack is randomized in an 8MB range but we do not control the contents of any large buffer on the executable stack.
Later, we discovered that two 128KB (MAX_ARG_STRLEN) copies of the LD_PRELOAD environment variable can be allocated onto the executable stack by ld.so's dl_main() and open_path() functions, automatically freed upon return from these functions, and re-allocated (but not overwritten) by Exim's 256KB stack-based group_list[].
In theory, the probability of returning into our shell-code (into these executable copies of LD_PRELOAD) is 1/32 (2128KB/8MB), higher than the 1/256 probability of returning-into-libc. In practice, this alternative Exim exploit has a good chance of obtaining a root-shell after 1174 runs -- instead of 3228=896 runs in theory, because the two 128KB copies of LD_PRELOAD are never perfectly aligned with Exim's 256KB group_list[] -- or 1174*2.5 seconds = 50 minutes.
Debian 9 and 10
Unlike Debian 8, Debian 9 and 10 are not vulnerable to offset2lib, a minor weakness in Linux's ASLR that coincidentally affects Step 1 (Clash) of our stack-clash exploits:
https://cybersecurity.upv.es/attacks/offset2lib/offset2lib.html https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d1fd836dcf00d2028c700c7e44d2c23404062c90
If we set RLIMIT_STACK to RLIM_INFINITY, the kernel still switches to the legacy bottom-up mmap() layout, and the libraries are randomized in the 1MB range above the address 0x40000000, but Exim's PIE is randomized in the 1MB range above the address 0x80000000 and the heap is randomized in the 32MB range above the PIE's .bss section. As a result:
-
the heap is always able to reach the stack, because its growth is never blocked by the libraries -- the theoretical probability of gaining eip control is 1/16, the probability calculated by our helper program;
-
the heap clashes with the stack around the address 0xA0000000, because the initial heap-stack distance is 1GB (0xC0000000-0x80000000) and can be covered with 512MB of heap memory and 512MB of stack memory.
Remote exploitation
Exim's string_sprintf() or glibc's vfprintf() can be used to remotely complete Steps 3 and 4 of the stack-clash; and the 256KB group_list[] in Exim's main() naturally consumes the 128KB of initial stack expansion in Step 2; but another 256KB group_list[] in Exim's exim_setugid() further decreases the start address of the stack and prevents us from remotely completing Step 2 and exploiting Exim.
======================================================================== IV.1.2. Sudo ========================================================================
Introduction
We discovered a vulnerability in Sudo's get_process_ttyname() for Linux: this function opens "/proc/[pid]/stat" (man proc) and reads the device number of the tty from field 7 (tty_nr). Unfortunately, these fields are space-separated and field 2 (comm, the filename of the command) can contain spaces (CVE-2017-1000367).
For example, if we execute Sudo through the symlink "./ 1 ", get_process_ttyname() calls sudo_ttyname_dev() to search for the non-existent tty device number "1" in the built-in search_devs[].
Next, sudo_ttyname_dev() calls the recursive function sudo_ttyname_scan() to search for this non-existent tty device number "1" in a breadth-first traversal of "/dev".
Last, we exploit this recursive function during its traversal of the world-writable "/dev/shm", and allocate hundreds of megabytes of heap memory from the filesystem (directory pathnames) instead of the stack (the command-line arguments and environment variables allocated by our other stack-clash exploits).
Step 1: Clash the stack with the heap
sudo_ttyname_scan() strdup()licates the pathnames of the directories and sub-directories that it traverses, but does not free() them until it returns. Each one of these "memleak-chunks" allocates at most 4KB (PATH_MAX) of heap memory.
Step 2: Move the stack-pointer to the start of the stack
The recursive calls to sudo_ttyname_scan() allocate 4KB (PATH_MAX) stack-frames that naturally consume the 128KB of initial stack expansion.
Step 3: Jump over the stack guard-page and into the heap
If the length of a directory pathname reaches 4KB (PATH_MAX), sudo_ttyname_scan() calls warning(), which calls strerror() and _(), which call gettext() and allow us to jump over the stack guard-page with an alloca() of up to 128KB (the LANGUAGE environment variable), as explained in II.3.3.
Step 4a: Smash the stack with the heap
The self-contained gettext() exploitation method malloc()ates and memcpy()es a "smashing-chunk" of up to 128KB (the OUTPUT_CHARSET environment variable) that smashes memcpy()'s stack-frame and return-address, as explained in II.3.4.
Debian 8.5
Step 1: Clash the stack with the heap
Debian 8.5 is vulnerable to CVE-2016-3672: if we set RLIMIT_STACK to RLIM_INFINITY, the kernel switches to the legacy bottom-up mmap() layout and disables the ASLR of Sudo's PIE and libraries, but still the initial heap-stack distance is randomized and roughly 2GB (0xC0000000-0x40000000 -- the start of the heap is randomized in a 32MB range above 0x40000000, and the end of the stack is randomized in the 8MB range below 0xC0000000).
To reach the start of the stack with the end of the heap, we allocate hundreds of megabytes of heap memory from the filesystem (directory pathnames), and:
-
the heap must be able to reach the stack -- on Debian 8.5, Sudo's libraries occupy about 3MB and hence block the growth of the heap with a probability of 3MB/32MB ~= 1/11;
-
when not blocked by the libraries, the heap must always reach the stack, even when the initial heap-stack distance is maximal (as detailed in IV.1.1.);
-
we cover half of the initial heap-stack distance with 1GB of heap memory (the memleak-chunks, strdup()licated directory pathnames);
-
we cover the other half of this distance with 1GB of stack memory (the maximum permitted by the kernel's 1/4 limit on the argument and environment strings) and thus reduce our on-disk inode usage;
-
we redirect sudo_ttyname_scan()'s traversal of /dev to /var/tmp (through a symlink planted in /dev/shm) to work around the small number of inodes available in /dev/shm.
After the heap reaches the stack and malloc() switches from brk() to mmap()s of 1MB:
-
the size of the free chunk left over at the end of the heap is a random variable in the [0B,4KB] range -- 4KB (PATH_MAX) is the approximate size of a memleak-chunk;
-
the final heap-stack distance (between the end of the heap and the start of the stack) is a random variable in the [8KB,4KB+128KB=132KB] range -- the size of a memleak-chunk plus 128KB (DEFAULT_TOP_PAD);
-
sudo_ttyname_scan() recurses a few more times and therefore allocates more stack memory, but this stack expansion is blocked by the heap and crashes into the stack guard-page after 16 recursions on average (132KB/4KB/2, where 132KB is the maximum final heap-stack distance, and 4KB is the size of sudo_ttyname_scan()'s stack-frame).
To solve this unexpected problem, we:
-
first, redirect sudo_ttyname_scan() to a directory tree "A" in /var/tmp that recurses and allocates stack memory, but does not allocate heap memory (each directory level contains only one entry, the sub-directory that is connected to the next directory level);
-
second, redirect sudo_ttyname_scan() to a directory tree "B" in /var/tmp that recurses and allocates heap memory (each directory level contains many entries), but does not allocate more stack memory (it simply consumes the stack memory that was already allocated by the directory tree "A"): it does not further expand the stack, and does not crash into the guard-page.
Finally, we increase the speed of our exploit and avoid thousands of useless recursions:
-
in each directory level traversed by sudo_ttyname_scan(), we randomly modify the names of its sub-directories until the first call to readdir() returns the only sub-directory that is connected to the next level of the directory tree (all other sub-directories allocate heap memory but are otherwise empty);
-
we dup2() Sudo's stdout and stderr to a pipe with no readers that terminates Sudo with a SIGPIPE if sudo_ttyname_scan() calls warning() and sudo_printf() (a failed exploit attempt, usually because the final heap-stack distance is much longer or shorter than the guard-page jump).
Step 2: Move the stack-pointer to the start of the stack
sudo_ttyname_scan() allocates a 4KB (PATH_MAX) stack-based pathbuf[] that naturally consumes the 128KB of initial stack expansion in fewer than 128KB/4KB=32 recursive calls.
The recursive calls to sudo_ttyname_scan() allocate less than 8MB of stack memory: the maximum number of recursions (PATH_MAX / strlen("/a") = 2K) multiplied by the size of sudo_ttyname_scan()'s stack-frame (4KB).
Step 3: Jump over the stack guard-page and into the heap
The length of the guard-page jump in gettext() is the length of the LANGUAGE environment variable (at most 128KB, MAX_ARG_STRLEN): we take a 64KB jump, well within the range of the final heap-stack distance; this jump then lands into the free chunk at the end of the heap, where the smashing-chunk will be allocated in Step 4a, with a probability of (smashing-chunk / (memleak-chunk + DEFAULT_TOP_PAD)).
If available, we assign "C.UTF-8" to the LC_ALL environment variable, and prepend "be" to our 64KB LANGUAGE environment variable, because these minimal locales do not interfere with our heap feng-shui.
Step 4a: Smash the stack with the heap
In gettext(), the smashing-chunk (a malloc() and memcpy() of the OUTPUT_CHARSET environment variable) must be allocated into the free chunk at the end of the heap, where the stack-frame of memcpy() is also allocated.
First, if the size of our memleak-chunks is exactly 4KB+8B (PATH_MAX+MALLOC_ALIGNMENT), then:
-
the size of the free chunk at the end of the heap is a random variable in the [0B,4KB] range;
-
the size of the free chunks left over at the end of the 1MB mmap()s is roughly 1MB%(4KB+8B)=2KB.
Second, if the size of our smashing-chunk is about 2KB+256B (PATH_MAX/2+NAME_MAX), then:
-
it is always larger than (and never allocated into) the free chunks at the end of the 1MB mmap()s;
-
it is smaller than (and allocated into) the free chunk at the end of the heap with a probability of roughly 1-(2KB+256B)/4KB.
Last, in each level of our directory tree "B", sudo_ttyname_scan() malloc()ates and realloc()ates an array of pointers to sub-directories, but these realloc()s prevent the smashing-chunk from being allocated into the free chunk at the end of the heap:
-
they create holes in the heap, where the smashing-chunk may be allocated to;
-
they may allocate the free chunk at the end of the heap, where the smashing-chunk should be allocated to.
To solve these problems, we carefully calculate the number of sub-directories in each level of our directory tree "B":
- we limit the size of the realloc()s -- and hence the size of the holes that they create -- to 4KB+2KB:
. either a memleak-chunk is allocated into such a hole, and the remainder is smaller than the smashing-chunk ("not a fit");
. or such a hole is not allocated, but it is larger than the largest free chunk at the end of the heap ("a worse fit");
- we gradually reduce the final size of the realloc()s in the last levels of our directory tree "B", and hence re-allocate the holes created in the previous levels.
In theory, on Debian 8.5, the probability of gaining control of eip is approximately 1/148, the product of:
-
(Step 1) the probability of reaching the stack with the heap: 1-3MB/32MB;
-
(Step 3) the probability of jumping over the stack guard-page and into the free chunk at the end of the heap: (2KB+256B) / (4KB+8B + 128KB);
-
(Step 4a) the probability of allocating the smashing-chunk into the free chunk at the end of the heap: 1-(2KB+256B)/4KB.
In practice, on Debian 8.5, this Sudo exploit:
-
gains eip control in 1 run out of 200, on average;
-
takes 2.8 seconds per run (on a 4GB Virtual Machine);
-
has a good chance of obtaining a root-shell after 200 * 2.8 seconds = 9 minutes;
-
uses 2GB of memory.
Note: we do not return-into-libc's system() in Step 4a because /bin/sh may be bash, which drops our escalated root privileges upon execution. Instead, we:
-
either return-into-libc's __gconv_find_shlib() function through find_module(), which loads this function's argument from -0x20(%ebp);
-
or return-into-libc's __libc_dlopen_mode() function through nss_load_library(), which loads this function's argument from -0x1c(%ebp);
-
search the libc for a relative pathname that contains a slash character (for example, "./fork.c") and pass its address to __gconv_find_shlib() or __libc_dlopen_mode();
-
symlink() our PIE exploit to this pathname, and let Sudo execute our _init() constructor as root, upon successful exploitation.
Debian 8.6
Unlike Debian 8.5, Debian 8.6 is not vulnerable to CVE-2016-3672: Sudo's PIE and libraries are always randomized, even if we set RLIMIT_STACK to RLIM_INFINITY; the probability of successfully returning-into-libc, after gaining eip control in Step 4a (Smash), is 1/256.
However, Debian 8.6 is still vulnerable to offset2lib, the minor weakness in Linux's ASLR that coincidentally affects Step 1 (Clash) of our stack-clash exploits:
-
if we set RLIMIT_STACK to 136MB (MIN_GAP) or less (the default is 8MB), then the initial heap-stack distance (between the start of the heap and the end of the stack) is minimal, a random variable in the [96MB,137MB] range;
-
instead of allocating 1GB of heap memory and 1GB of stack memory to clash the stack with the heap, we merely allocate 137MB of heap memory (directory pathnames from our directory tree "B") and no stack memory.
In theory, on Debian 8.6, the probability of gaining eip control is 1/134 (instead of 1/148 on Debian 8.5) because the growth of the heap is never blocked by Sudo's libraries; and in practice, this Sudo exploit takes only 0.15 second per run (instead of 2.8 on Debian 8.5).
Independent exploitation
The vulnerability that we discovered in Sudo's get_process_ttyname() function for Linux (CVE-2017-1000367) is exploitable independently of its stack-clash repercussions: through this vulnerability, a local user can pretend that his tty is any character device on the filesystem, and after two race conditions, he can pretend that his tty is any file on the filesystem.
On an SELinux-enabled system, if a user is Sudoer for a command that does not grant him full root privileges, he can overwrite any file on the filesystem (including root-owned files) with this command's output, because relabel_tty() (in src/selinux.c) calls open(O_RDWR|O_NONBLOCK) on his tty and dup2()s it to the command's stdin, stdout, and stderr.
To exploit this vulnerability, we:
-
create a directory "/dev/shm/_tmp" (to work around /proc/sys/fs/protected_symlinks), and a symlink "/dev/shm/_tmp/_tty" to a non-existent pty "/dev/pts/57", whose device number is 34873;
-
run Sudo through a symlink "/dev/shm/_tmp/ 34873 " that spoofs the device number of this non-existent pty;
-
set the flag CD_RBAC_ENABLED through the command-line option "-r role" (where "role" can be our current role, for example "unconfined_r");
-
monitor our directory "/dev/shm/_tmp" (for an IN_OPEN inotify event) and wait until Sudo opendir()s it (because sudo_ttyname_dev() cannot find our non-existent pty in "/dev/pts/");
-
SIGSTOP Sudo, call openpty() until it creates our non-existent pty, and SIGCONT Sudo;
-
monitor our directory "/dev/shm/_tmp" (for an IN_CLOSE_NOWRITE inotify event) and wait until Sudo closedir()s it;
-
SIGSTOP Sudo, replace the symlink "/dev/shm/_tmp/_tty" to our now-existent pty with a symlink to the file that we want to overwrite (for example "/etc/passwd"), and SIGCONT Sudo;
-
control the output of the command executed by Sudo (the output that overwrites "/etc/passwd"):
. either through a command-specific method;
. or through a general method such as "--\nHELLO\nWORLD\n" (by default, getopt() prints an error message to stderr if it does not recognize an option character).
To reliably win the two SIGSTOP races, we preempt the Sudo process: we setpriority() it to the lowest priority, sched_setscheduler() it to SCHED_IDLE, and sched_setaffinity() it to the same CPU as our exploit.
[john@localhost ~]$ head -n 8 /etc/passwd root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin adm:x:3:4:adm:/var/adm:/sbin/nologin lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt
[john@localhost ~]$ sudo -l [sudo] password for john: ... User john may run the following commands on localhost: (ALL) /usr/bin/sum
[john@localhost ~]$ ./Linux_sudo_CVE-2017-1000367 /usr/bin/sum $'--\nHELLO\nWORLD\n' [sudo] password for john:
[john@localhost ~]$ head -n 8 /etc/passwd /usr/bin/sum: unrecognized option '-- HELLO WORLD ' Try '/usr/bin/sum --help' for more information. ogin adm:x:3:4:adm:/var/adm:/sbin/nologin lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
======================================================================== IV.1.3. ld.so "hwcap" exploit ========================================================================
"ld.so and ld-linux.so* find and load the shared libraries needed by a program, prepare the program to run, and then run it." (man ld.so)
Through ld.so, most SUID and SGID binaries on most i386 Linux distributions are exploitable. For example: Debian 7, 8, 9, 10; Fedora 23, 24, 25; CentOS 5, 6, 7.
Debian 8.5
Step 1: Clash the stack with anonymous mmap()s
The minimal malloc() implementation in ld.so calls mmap(), not brk(), to obtain memory from the system, and it never calls munmap(). To reach the start of the stack with anonymous mmap()s, we:
-
set RLIMIT_STACK to RLIM_INFINITY and switch from the default top-down mmap() layout to the legacy bottom-up mmap() layout;
-
cover half of the initial mmap-stack distance (0xC0000000-0x40000000=2GB) with 1GB of stack memory (the maximum permitted by the kernel's 1/4 limit on the argument and environment strings);
-
cover the other half of this distance with 1GB of anonymous mmap()s, through multiple LD_AUDIT environment variables that permanently leak millions of audit_list structures (CVE-2017-1000366) in process_envvars() and process_dl_audit() (elf/rtld.c).
Step 2: Move the stack-pointer to the start of the stack
To consume the 128KB of initial stack expansion, we simply pass 128KB of argv[] and envp[] pointers to execve(), as explained in II.3.2.
Step 3: Jump over the stack guard-page and into the anonymous mmap()s
_dl_init_paths() (elf/dl-load.c), which is called by dl_main() after process_envvars(), alloca()tes llp_tmp, a stack-based buffer large enough to hold the LD_LIBRARY_PATH environment variable and any combination of Dynamic String Token (DST) replacement strings. To calculate the size of llp_tmp, _dl_init_paths() must:
-
first, scan LD_LIBRARY_PATH and count all DSTs ($LIB, $PLATFORM, and $ORIGIN);
-
second, multiply the number of DSTs by the length of the longest DST replacement string (on Debian, $LIB is replaced by the 18-char-long "lib/i386-linux-gnu", $PLATFORM by "i386" or "i686", and $ORIGIN by the pathname of the program's directory, for example "/bin" or "/usr/sbin" -- the longest DST replacement string is usually "lib/i386-linux-gnu");
-
last, add the length of the original LD_LIBRARY_PATH.
Consequently, if LD_LIBRARY_PATH contains many DSTs that are replaced by the shortest DST replacement string, then llp_tmp is large but not fully written to, and can be used to jump over the stack guard-page and into the anonymous mmap()s.
Our ld.so exploits do not use $ORIGIN because it is ignored by several distributions and glibc versions; for example:
2010-12-09 Andreas Schwab schwab@redhat.com
* elf/dl-object.c (_dl_new_object): Ignore origin of privileged
program.
Index: glibc-2.12-2-gc4ccff1/elf/dl-object.c
--- glibc-2.12-2-gc4ccff1.orig/elf/dl-object.c +++ glibc-2.12-2-gc4ccff1/elf/dl-object.c @@ -214,6 +214,9 @@ _dl_new_object (char realname, const ch out: new->l_origin = origin; } + else if (INTUSE(__libc_enable_secure) && type == lt_executable) + / The origin of a privileged program cannot be trusted. / + new->l_origin = (char ) -1;
return new; }
Step 4b: Smash an anonymous mmap() with the stack
Before _dl_init_paths() returns to dl_main() and jumps back from the anonymous mmap()s into the stack, we overwrite the block of mmap()ed memory malloc()ated by _dl_important_hwcaps() with the contents of the stack-based buffer llp_tmp.
- The block of memory malloc()ated by _dl_important_hwcaps() is divided in two:
. The first part (the "hwcap-pointers") is an array of r_strlenpair structures that point to the hardware-capability strings stored in the second part of this memory block. The second part (the "hwcap-strings") contains strings of hardware-capabilities that are appended to the pathnames of trusted directories, such as "/lib/" and "/lib/i386-linux-gnu/", when open_path() searches for audit libraries (LD_AUDIT), preload libraries (LD_PRELOAD), or dependent libraries (DT_NEEDED).
For example, on Debian, when open_path() finds "libc.so.6" in
"/lib/i386-linux-gnu/i686/cmov/", "i686/cmov/" is such a
hardware-capability string.
- To overwrite the block of memory malloc()ated by _dl_important_hwcaps() with the contents of the stack-based buffer llp_tmp, we divide our LD_LIBRARY_PATH environment variable in two:
. The first, static part (our "good-write") overwrites the first hardware-capability string with characters that we do control. The second, dynamic part (our "bad-write") overwrites the last hardware-capability strings with characters that we do not control (the short DST replacement strings that enlarge llp_tmp and allow us to jump over the stack guard-page).
If our 16-byte-aligned good-write overwrites the 8-byte-aligned first hardware-capability string with the 8-byte pattern "/../tmp/", and if we append the trusted directory "/lib" to our LD_LIBRARY_PATH, then (after _dl_init_paths() returns to dl_main()):
-
dlmopen_doit() tries to load an LD_AUDIT library "a" (our memory leak from Step 1);
-
_dl_map_object() searches for "a" in the trusted directory "/lib" from our LD_LIBRARY_PATH;
-
open_path() finds our library "a" in "/lib//../tmp//../tmp//../tmp/" because we overwrote the first hardware-capability string with the pattern "/../tmp/";
-
dl_open_worker() executes our library's _init() constructor, as root.
In theory, this exploit's probability of success depends on:
- (event A) the size of rtld_search_dirs.dirs[0], an array of r_search_path_elem structures that are malloc()ated by _dl_init_paths() after the _dl_important_hwcaps(), and must be allocated above the stack (below 0xC0000000), not below the stack where it would interfere with Steps 3 (Jump) and 4b (Smash):
P(A) = 1 - size of rtld_search_dirs.dirs[0] / max stack randomization
- (event B) the size of the hwcap-pointers and the size of our good-write, which must overwrite the first hardware-capability string, but not the first hardware-capability pointer (to this string):
P(B|A) = MIN(size of hwcap-pointers, size of good-write) / (max stack randomization - size of rtld_search_dirs.dirs[0])
- (event C) the size of the hwcap-strings and the size of our bad-write, which must not write past the end of hwcap-strings; but we guarantee that size of hwcap-strings >= size of good-write + size of bad-write:
P(C|B) = 1
In practice, we use the LD_HWCAP_MASK environment variable to maximize this exploit's probability of success, because:
-
the size of the hwcap-pointers -- which act as a cushion that absorbs the excess of good-write without crashing,
-
the size of the hwcap-strings -- which act as a cushion that absorbs the excess of good-write and bad-write without crashing,
-
and the size of rtld_search_dirs.dirs[0],
are all proportional to 2^N, where N is the number of supported hardware-capabilities that we enable in LD_HWCAP_MASK.
For example, on Debian 8.5, this exploit:
-
has a 1/151 probability of success;
-
takes 5.5 seconds per run (on a 4GB Virtual Machine);
-
has a good chance of obtaining a root-shell after 151 * 5.5 seconds = 14 minutes.
Debian 8.6
Unlike Debian 8.5, Debian 8.6 is not vulnerable to CVE-2016-3672, but our ld.so "hwcap" exploit is a data-only attack and is not affected by the ASLR of the libraries and PIEs.
Debian 9 and 10
Unlike Debian 8, Debian 9 and 10 are not vulnerable to offset2lib: if we set RLIMIT_STACK to RLIM_INFINITY, the libraries are randomized above the address 0x40000000, but the PIE is randomized above 0x80000000 (instead of 0x40000000 before the offset2lib patch).
Unfortunately, we discovered a vulnerability in the offset2lib patch (CVE-2017-1000370): if the PIE is execve()d with 1GB of argument or environment strings (the maximum permitted by the kernel's 1/4 limit) then the stack occupies the address 0x80000000, and the PIE is mapped above the address 0x40000000 instead, directly below the libraries. This vulnerability effectively nullifies the offset2lib patch, and allows us to reuse our Debian 8 exploit against Debian 9 and 10.
$ ./Linux_offset2lib Run #1... CVE-2017-1000370 triggered 40076000-40078000 r-xp 00000000 00:26 25041 /tmp/Linux_offset2lib 40078000-40079000 r--p 00001000 00:26 25041 /tmp/Linux_offset2lib 40079000-4009b000 rw-p 00002000 00:26 25041 /tmp/Linux_offset2lib 4009b000-400c0000 r-xp 00000000 fd:00 8463588 /usr/lib/ld-2.24.so 400c0000-400c1000 r--p 00024000 fd:00 8463588 /usr/lib/ld-2.24.so 400c1000-400c2000 rw-p 00025000 fd:00 8463588 /usr/lib/ld-2.24.so 400c2000-400c4000 r--p 00000000 00:00 0 [vvar] 400c4000-400c6000 r-xp 00000000 00:00 0 [vdso] 400c6000-400c8000 rw-p 00000000 00:00 0 400cf000-402a3000 r-xp 00000000 fd:00 8463595 /usr/lib/libc-2.24.so 402a3000-402a4000 ---p 001d4000 fd:00 8463595 /usr/lib/libc-2.24.so 402a4000-402a6000 r--p 001d4000 fd:00 8463595 /usr/lib/libc-2.24.so 402a6000-402a7000 rw-p 001d6000 fd:00 8463595 /usr/lib/libc-2.24.so 402a7000-402aa000 rw-p 00000000 00:00 0 7fcf1000-bfcf2000 rw-p 00000000 00:00 0 [stack]
Caveats
- On Fedora and CentOS, this ld.so "hwcap" exploit fails against /usr/bin/passwd and /usr/bin/chage (but it works against all other SUID-root binaries) because of SELinux:
type=AVC msg=audit(1492091008.983:414): avc: denied { execute } for pid=2169 comm="passwd" path="/var/tmp/a" dev="dm-0" ino=12828063 scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0
type=AVC msg=audit(1492092997.581:487): avc: denied { execute } for pid=2648 comm="chage" path="/var/tmp/a" dev="dm-0" ino=12828063 scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0
- It fails against recent versions of Sudo that specify an RPATH such as "/usr/lib/sudo": _dl_map_object() first searches for our LD_AUDIT library in RPATH, but open_path() fails to find our library in "/usr/lib/sudo//../tmp/" and crashes as soon as it reaches an overwritten hwcap-pointer.
This problem can be solved by a 16-byte pattern "///../../../tmp/" (instead of the 8-byte pattern "/../tmp/") but the exploit's probability of success would be divided by two.
- On Ubuntu, this ld.so "hwcap" exploit always fails, because of the following patch:
Description: pro-actively disable LD_AUDIT for setuid binaries, regardless of where the libraries are loaded from. This is to try to make sure that CVE-2010-3856 cannot sneak back in. Upstream is unlikely to take this, since it limits the functionality of LD_AUDIT. Author: Kees Cook kees@ubuntu.com
Index: eglibc-2.15/elf/rtld.c
--- eglibc-2.15.orig/elf/rtld.c 2012-05-09 10:05:29.456899131 -0700 +++ eglibc-2.15/elf/rtld.c 2012-05-09 10:38:53.952009069 -0700 @@ -2529,7 +2529,7 @@ while ((p = (strsep) (&str, ":")) != NULL) if (p[0] != '\0' && (__builtin_expect (! __libc_enable_secure, 1) - || strchr (p, '/') == NULL)) + )) { / This is using the local malloc, not the system malloc. The memory can never be freed. /
======================================================================== IV.1.4. ld.so ".dynamic" exploit ========================================================================
To exploit ld.so without the LD_AUDIT memory leak, we rely on a second vulnerability that we discovered in the offset2lib patch (CVE-2017-1000371):
if we set RLIMIT_STACK to RLIM_INFINITY, and allocate nearly 1GB of stack memory (the maximum permitted by the kernel's 1/4 limit on the argument and environment strings) then the stack grows down to almost 0x80000000, and because the PIE is mapped above 0x80000000, the minimum distance between the end of the PIE's read-write segment and the start of the stack is 4KB (the stack guard-page).
$ ./Linux_offset2lib 0x3f800000 Run #1... Run #2... Run #3... Run #796... Run #797... Run #798... CVE-2017-1000371 triggered 4007b000-400a0000 r-xp 00000000 fd:00 8463588 /usr/lib/ld-2.24.so 400a0000-400a1000 r--p 00024000 fd:00 8463588 /usr/lib/ld-2.24.so 400a1000-400a2000 rw-p 00025000 fd:00 8463588 /usr/lib/ld-2.24.so 400a2000-400a4000 r--p 00000000 00:00 0 [vvar] 400a4000-400a6000 r-xp 00000000 00:00 0 [vdso] 400a6000-400a8000 rw-p 00000000 00:00 0 400af000-40283000 r-xp 00000000 fd:00 8463595 /usr/lib/libc-2.24.so 40283000-40284000 ---p 001d4000 fd:00 8463595 /usr/lib/libc-2.24.so 40284000-40286000 r--p 001d4000 fd:00 8463595 /usr/lib/libc-2.24.so 40286000-40287000 rw-p 001d6000 fd:00 8463595 /usr/lib/libc-2.24.so 40287000-4028a000 rw-p 00000000 00:00 0 8000a000-8000c000 r-xp 00000000 00:26 25041 /tmp/Linux_offset2lib 8000c000-8000d000 r--p 00001000 00:26 25041 /tmp/Linux_offset2lib 8000d000-8002f000 rw-p 00002000 00:26 25041 /tmp/Linux_offset2lib 80030000-bf831000 rw-p 00000000 00:00 0 [heap]
Note: in this example, the "[stack]" is incorrectly displayed as the "[heap]" by show_map_vma() (in fs/proc/task_mmu.c).
This completes Step 1: we clash the stack with the PIE's read-write segment; we complete the remaining steps as in the "hwcap" exploit:
-
Step 2: we consume the initial stack expansion with 128KB of argv[] and envp[] pointers;
-
Step 3: we jump over the stack guard-page and into the PIE's read-write segment with llp_tmp's alloca() (in _dl_init_paths());
-
Step 4b: we smash the PIE's read-write segment with llp_tmp's good-write and bad-write (in _dl_init_paths()); we can smash the following sections:
-
.data and .bss: but we discarded this application-specific approach;
-
.got: although protected by Full RELRO (Full RELocate Read-Only, GNU_RELRO and BIND_NOW) the .got is still writable when we smash it in _dl_init_paths(); however, within ld.so, the .got is written to but never read from, and we therefore discarded this approach;
-
.dynamic: our favored approach.
On i386, the .dynamic section is an array of Elf32_Dyn structures (an int32 d_tag, and the union of uint32 d_val and uint32 d_ptr) that contains entries such as:
-
DT_STRTAB, a pointer to the PIE's .dynstr section (a read-only string table): its d_tag (DT_STRTAB) is read (by elf_get_dynamic_info()) before we smash it in _dl_init_paths(), but its d_ptr is read (by _dl_map_object_deps()) after we smash it in _dl_init_paths();
-
DT_NEEDED, an offset into the .dynstr section: the pathname of a dependent library that must be loaded by _dl_map_object_deps().
If we overwrite the entire .dynamic section with the following 8-byte pattern (an Elf32_Dyn structure):
-
a DT_NEEDED d_tag,
-
a d_val equal to half the address of our own string table on the stack (16MB of argument strings, enough to defeat the 8MB stack randomization),
then _dl_map_object_deps() reads the pathname of this dependent library from DT_STRTAB.d_ptr + DT_NEEDED.d_val = our_strtab/2 + our_strtab/2 = our_strtab, and loads our own library, as root. This 8-byte pattern is simple, but poses two problems:
-
DT_NEEDED is an int32 equal to 1, but we smash the .dynamic section with a string copy that cannot contain null-bytes: to solve this first problem we use DT_AUXILIARY instead, which is equivalent but equal to 0x7ffffffd;
-
ld.so crashes before it returns from dl_main() (before it calls _dl_init() and executes our library's _init() constructor):
. in _dl_map_object_deps() because of our DT_AUXILIARY entry;
. in version_check_doit() because we overwrote the DT_VERNEED entry;
. in _dl_relocate_object() because we overwrote the DT_REL, DT_RELSZ, and DT_RELCOUNT entries.
To solve this second problem, we could overwrite the .dynamic section with a more complicated pattern that repairs these entries, but our exploit's probability of success would decrease significantly.
Instead, we take control of ld.so's execution flow as soon as _dl_map_object_deps() loads our library:
-
our library contains three executable LOAD segments,
-
but only the first and last segments are sanity-checked by _dl_map_object_from_fd() and _dl_map_segments(),
-
and all segments except the first are mmap()ed with MAP_FIXED by _dl_map_segments(),
-
so we can mmap() our second segment anywhere -- we mmap() it on top of ld.so's executable segment,
-
and return into our own code (instead of ld.so's) as soon as this second mmap() system-call returns.
Probabilities
The "hwcap" exploit taught us that this ".dynamic" exploit's probability of success depends on:
-
the size of the cushion below the .dynamic section, which can absorb the excess of "good-write" without crashing: the padding bytes between the start of the PIE's read-write segment and the start of its first read-write section;
-
the size of the cushion above the .dynamic section, which can absorb the excess of "good-write" and "bad-write" without crashing: the .got, .data, and .bss sections.
If we guarantee that (cushion above .dynamic > good-write + bad-write), then the theoretical probability of success is approximately:
MIN(cushion below .dynamic, good-write) / max stack randomization
The maximum size of the cushion below the .dynamic section is 4KB (one page) and hence the maximum probability of success is 4KB/8MB=1/2048. In practice, on Ubuntu 16.04.2:
-
the highest probability is 1/2589 (/bin/su) and the lowest probability is 1/9225 (/usr/lib/eject/dmcrypt-get-device);
-
each run uses 1GB of memory and takes 1.5 seconds (on a 4GB Virtual Machine);
-
this ld.so ".dynamic" exploit has a good chance of obtaining a root-shell after 2589 * 1.5 seconds ~= 1 hour.
======================================================================== IV.1.5. /bin/su ========================================================================
As we were drafting this advisory, we discovered a general method for completing Step 1 (Clash) of the stack-clash exploitation: the Linux kernel limits the size of the command-line arguments and environment variables to 1/4 of the RLIMIT_STACK, but it imposes this limit on the argument and environment strings, not on the argv[] and envp[] pointers to these strings (CVE-2017-1000365).
On i386, if we set RLIMIT_STACK to RLIM_INFINITY, the maximum number of argv[] and envp[] pointers is 1G (1/4 of the RLIMIT_STACK, divided by 1B, the minimum size of an argument or environment string). In theory, the maximum size of the initial stack is therefore 1G*(1B+4B)=5GB. In practice, this would exhaust the address-space and allows us to clash the stack with the memory region that is mapped below, without an application-specific memory leak.
This discovery allowed us to write alternative versions of our stack-clash exploits; for example:
-
an ld.so "hwcap" exploit against Ubuntu: we replace the LD_AUDIT memory leak with 2GB of stack memory (1GB of argument and environment strings, and 1GB of argv[] and envp[] pointers) and replace the LD_AUDIT library with an LD_PRELOAD library;
-
an ld.so ".dynamic" exploit against systems vulnerable to offset2lib: we reach the end of the PIE's read-write segment with only 128MB of stack memory (argument and environment strings and pointers).
These proofs-of-concept demonstrate a general method for completing Step 1 (Clash), but they are much slower than their original versions (10-20 seconds per run) because they pass millions of argv[] and envp[] pointers to execve().
Moreover, this discovery allowed us to exploit SUID binaries through general methods that do not depend on application-specific or ld.so vulnerabilities; if a SUID binary calls setlocale(LC_ALL, ""); and gettext() (or a derivative such as strerror() or _()), then it is exploitable:
-
Step 1: we clash the stack with the heap through millions of argument and environment strings and pointers;
-
Step 2: we consume the initial stack expansion with 128KB of argument and environment pointers;
-
Step 3: we jump over the stack guard-page and into the heap with the alloca()tion of the LANGUAGE environment variable in gettext();
-
Step 4a: we smash the stack with the malloc()ation of the OUTPUT_CHARSET environment variable in gettext() and thus gain control of eip.
For example, we exploited Debian's /bin/su (from the shadow-utils): its main() function calls setlocale() and save_caller_context(), which calls gettext() (through _()) if its stdin is not a tty.
Debian 8.5
Debian 8.5 is vulnerable to CVE-2016-3672: we set RLIMIT_STACK to RLIM_INFINITY and disable ASLR, clash the stack with the heap through 2GB of argument and environment strings and pointers (1GB of strings, 1GB of pointers), and return-into-libc's system() or __libc_dlopen():
-
the system() version uses 4GB of memory (2GB in the /bin/su process, and 2GB in the process fork()ed by system());
-
the __libc_dlopen() version uses only 2GB of memory, but ebp must point to our smashed data on the stack.
Debian 8.6
Debian 8.6 is vulnerable to offset2lib but not to CVE-2016-3672: we must brute-force the libc's ASLR (8 bits of entropy), but we clash the stack with the heap through only 128MB of argument and environment strings and pointers -- this /bin/su exploit can be parallelized.
======================================================================== IV.1.6. Grsecurity/PaX ========================================================================
https://grsecurity.net/
In 2010, grsecurity/PaX introduced a configurable stack guard-page: its size can be modified through /proc/sys/vm/heap_stack_gap and is 64KB by default (unlike the hard-coded 4KB stack guard-page in the vanilla kernel).
Unfortunately, a 64KB stack guard-page is not large enough, and can be jumped over with ld.so or gettext() (CVE-2017-1000377); for example, we were able to gain eip control against Sudo, but we were unable to obtain a root-shell or gain eip control against another application, because grsecurity/PaX imposes the following security measures:
-
it restricts the RLIMIT_STACK of SUID binaries to 8MB, which prevents us from switching to the legacy bottom-up mmap() layout (Step 1);
-
it restricts the argument and environment strings to 512KB, which prevents us from clashing the stack through megabytes of command-line arguments and environment variables (Step 1);
-
it randomizes the PIE and libraries with 16 bits of entropy (instead of 8 bits in vanilla), which prevents us from brute-forcing the ASLR and returning-into-libc (Step 4a);
-
it implements /proc/sys/kernel/grsecurity/deter_bruteforce (enabled by default), which limits the number of SUID crashes to 1 every 15 minutes (all Steps) and makes exploitation impossible.
Sudo
The vulnerability that we discovered in Sudo's get_process_ttyname() (CVE-2017-1000367) allows us to:
-
Step 1: clash the stack with 3GB of heap memory from the filesystem (directory pathnames) and bypass grsecurity/PaX's 512KB limit on the argument and environment strings;
-
Step 2: consume the 128KB of initial stack expansion with 3MB of recursive function calls and avoid grsecurity/PaX's 8MB restriction on the RLIMIT_STACK;
-
Step 3: jump over grsecurity/PaX's 64KB stack guard-page with a 128KB (MAX_ARG_STRLEN) alloca()tion of the LANGUAGE environment variable in gettext();
-
Step 4a: smash the stack with a 128KB (MAX_ARG_STRLEN) malloc()ation of the OUTPUT_CHARSET environment variable in gettext() -- the "smashing-chunk" -- and thus gain control of eip.
In Step 1, we nearly exhaust the address-space until finally malloc() switches from brk() to 1MB mmap()s and reaches the start of the stack with the very last 1MB mmap() that we allocate. The exact amount of memory that we must allocate to reach the stack with our last 1MB mmap() depends on the sum of three random variables: the 256MB randomization of the stack, the 64MB randomization of the heap, and the 1MB randomization of the NULL region.
To maximize the probability of jumping over the stack guard-page, into our last 1MB mmap() below the stack, and overwriting a return-address on the stack with our smashing-chunk:
-
(Step 1) we must allocate the mean amount of memory to reach the stack with our last 1MB mmap(): the sum of three uniform random variables is not uniform (https://en.wikipedia.org/wiki/Irwin-Hall_distribution), but the values within the 256MB-64MB-1MB=191MB plateau at the center of this bell-shaped probability distribution occur with a uniform and maximum probability of (1MB64MB)/(1MB64MB*256MB)=1/256MB;
-
(Step 1) the end of our last 1MB mmap() must be allocated at a distance within [stack guard-page (64KB), guard-page jump (128KB)] below the start of the stack: the guard-page jump (Step 3) then lands at a distance d within [0, guard-page jump - stack guard-page (64KB)] below the end of our last 1MB mmap();
-
(Step 4a) the end of our smashing-chunk must be allocated at the end of our last 1MB mmap(), above the landing-point of the guard-page jump: our smashing-chunk then overwrites a return-address on the stack, below the landing-point of the guard-page jump.
In theory, this probability is roughly:
SUM(d = 1; d < guard-page jump - stack guard-page; d++) d / (256MB*1MB)
~= ((guard-page jump - stack guard-page)^2 / 2) / (256MB*1MB)
~= 1 / 2^17
In practice, we tested this Sudo proof-of-concept on an i386 Debian 8.6 protected by the linux-grsec package from the jessie-backports, but we manually disabled /proc/sys/kernel/grsecurity/deter_bruteforce:
-
it uses 3GB of memory, and 800K on-disk inodes;
-
it takes 5.5 seconds per run (on a 4GB Virtual Machine);
-
it has a good chance of gaining eip control after 2^17 * 5.5 seconds = 200 hours; in our test:
PAX: From 192.168.56.1: execution attempt in:
However, brute-forcing the ASLR to obtain a root-shell would take ~1500 years and makes exploitation impossible.
Moreover, if we enable /proc/sys/kernel/grsecurity/deter_bruteforce, gaining eip control would take ~1365 days, and obtaining a root-shell would take thousands of years.
======================================================================== IV.1.7. 64-bit exploitation ========================================================================
Introduction
The address-space of a 64-bit process is so vast that we initially thought it was impossible to clash the stack with another memory region; we were wrong.
Linux's execve() first randomizes the end of the mmap region (which grows top-down by default) and then randomizes the end of the stack region (which grows down, on x86). On amd64, the initial mmap-stack distance (between the end of the mmap region and the end of the stack region) is minimal when RLIMIT_STACK is lower than or equal to MIN_GAP (mmap_base() in arch/x86/mm/mmap.c), and then:
- the end of the mmap region is equal to (as calculated by arch_pick_mmap_layout() in arch/x86/mm/mmap.c):
mmap_end = TASK_SIZE - MIN_GAP - arch_mmap_rnd()
where:
. TASK_SIZE is the highest address of the user-space (0x7ffffffff000)
. MIN_GAP = 128MB + stack_maxrandom_size()
. stack_maxrandom_size() is ~16GB (or ~4GB if the kernel is vulnerable to CVE-2015-1593, but we do not consider this case here)
. arch_mmap_rnd() is a random variable in the [0B,1TB] range
- the end of the stack region is equal to (as calculated by randomize_stack_top() in fs/binfmt_elf.c):
stack_end = TASK_SIZE - "stack_rand"
where:
. "stack_rand" is a random variable in the [0, stack_maxrandom_size()] range
- the initial mmap-stack distance is therefore equal to:
stack_end - mmap_end = MIN_GAP + arch_mmap_rnd() - "stack_rand"
= 128MB + stack_maxrandom_size() - "stack_rand" + arch_mmap_rnd()
= 128MB + StackRand + MmapRand
where:
. StackRand = stack_maxrandom_size() - "stack_rand", a random variable in the [0B,16GB] range
. MmapRand = arch_mmap_rnd(), a random variable in the [0B,1TB] range
Consequently, the minimum initial mmap-stack distance is only 128MB (CVE-2017-1000379), and:
-
On kernels vulnerable to offset2lib, the heap of a PIE (which is mapped at the end of the mmap region) is mapped below and close to the stack with a good probability (~1/700). We can therefore clash the stack with the heap in Step 1, jump over the stack guard-page and into the heap in Step 3, and smash the stack with the heap and gain control of rip in Step 4a (after 6 hours on average). However, because the addresses of all executable regions contain null-bytes, and because most of our stack-smashes in Step 4a are string operations (except the getaddrinfo() method), we were unable to transform such a rip control into arbitrary code execution.
-
On all kernels, either a PIE or ld.so is mapped directly below the stack with a good probability (~1/17000) -- the end of the PIE's or ld.so's read-write segment is then equal to the start of the stack guard-page. We can therefore adapt our ld.so "hwcap" exploit to amd64 and obtain root privileges through most SUID binaries on most Linux distributions (after 5 hours on average).
Kernels vulnerable to offset2lib, local Exim proof-of-concept
Exim's binary is usually a PIE, mapped at the end of the mmap region; and the heap, which always grows up and is randomized above the end of the binary, is therefore randomized above the end of the mmap region (arch_randomize_brk() in arch/x86/kernel/process.c):
heap_start = mmap_end + "heap_rand"
where "heap_rand" is a random variable in the [0B,32MB] range (negligible and ignored here). For example, on Debian 8.5:
cat /proc/"pidof -s /usr/sbin/exim4
"/maps
... 7fa6410d6000-7fa6411c8000 r-xp 00000000 08:01 14574 /usr/sbin/exim4 7fa6413b4000-7fa6413bd000 rw-p 00000000 00:00 0 7fa6413c5000-7fa6413c7000 rw-p 00000000 00:00 0 7fa6413c7000-7fa6413c9000 r--p 000f1000 08:01 14574 /usr/sbin/exim4 7fa6413c9000-7fa6413d2000 rw-p 000f3000 08:01 14574 /usr/sbin/exim4 7fa6413d2000-7fa6413d7000 rw-p 00000000 00:00 0 7fa641b34000-7fa641b76000 rw-p 00000000 00:00 0 [heap] 7ffdf3e53000-7ffdf3ed6000 rw-p 00000000 00:00 0 [stack] 7ffdf3f3c000-7ffdf3f3e000 r-xp 00000000 00:00 0 [vdso] 7ffdf3f3e000-7ffdf3f40000 r--p 00000000 00:00 0 [vvar] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
To reach the start of the stack with the end of the heap (through the -p memory leak in Exim) in Step 1 of our stack-clash, we must minimize the initial heap-stack distance, and hence the initial mmap-stack distance, and set RLIMIT_STACK to MIN_GAP (~16GB). This limits the size of our -p argument strings on the stack to 16GB/4=4GB, and because we then leak the same amount of heap memory through -p, the initial heap-stack distance must be:
-
longer than 4GB (the stack must be able to contain the -p argument strings);
-
shorter than 8GB (the end of the heap must be able to reach the start of the stack during the -p memory leak).
The initial heap-stack distance (approximately the initial mmap-stack distance, 128MB + StackRand + MmapRand, but we ignore the 128MB term here) follows a trapezoidal Irwin-Hall distribution, and the [4GB,8GB] range is within the first non-uniform area of this trapezoid, so the probability that the initial heap-stack distance is in this range is:
SUM(d = 4GB; d < 8GB; d++) d / (16GB * 1TB)
= SUM(d = 0; d < 4GB; d++) (4GB + d) / (16GB * 1TB)
= SUM(d = 0; d < 2^32; d++) (2^32 + d) / (2^34 * 2^40)
~= ((2^32)(2^32) + (2^32)(2^32) / 2) / (2^74)
~= 3 / 2^11
~= 1 / 682
The probability of gaining rip control after the heap reaches the stack is ~1/16 (as calculated by a 64-bit version of the small helper program presented in IV.1.1.), and the final probability of gaining rip control with our local Exim proof-of-concept is:
(3 / 2^11) * (1/16) ~= 1 / 10922
On our 8GB Debian 8.7 test machine, this proof-of-concept takes roughly 2 seconds per run, and has a good chance of gaining rip control after 10922 * 2 seconds ~= 6 hours:
gdb /usr/sbin/exim4 core.6049
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 ... This GDB was configured as "x86_64-linux-gnu". Core was generated by `/usr/sbin/exim4 -p0000000000000000000000000000000000000000000000000000000000000'. Program terminated with signal SIGSEGV, Segmentation fault.
0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:41
41 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such file or directory. (gdb) x/i $rip => 0x7ffab1be7061 <__memcpy_sse2_unaligned+65>: retq (gdb) x/xg $rsp 0x7ffb9b294a48: 0x4141414141414141
Kernels vulnerable to offset2lib, ld.so ".dynamic" exploit
Since kernels vulnerable to offset2lib map PIEs below and close to the stack, we tried to adapt our ld.so ".dynamic" exploit to amd64. MIN_GAP guarantees a minimum distance of 128MB between the theoretical end of the mmap region and the end of the stack, but the stack then grows down to store the argument and environment strings, and may therefore occupy the theoretical end of the mmap region (where nothing has been mapped yet). Consequently, the end of the mmap region (where the PIE will be mapped) slides down to the first available address, directly below the stack guard-page and the initial stack expansion (described in II.3.2.):
7ffbb7e51000-7ffbb7e53000 r-xp 00000000 fd:03 4465810 /tmp/test64 ... 7ffbb8053000-7ffbb808c000 rw-p 00002000 fd:03 4465810 /tmp/test64 7ffbb808d000-7ffc180ae000 rw-p 00000000 00:00 0 [heap] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Note: in this example, the "[stack]" is, again, incorrectly displayed as the "[heap]" by show_map_vma() (in fs/proc/task_mmu.c).
This layout is ideal for our stack-clash exploits, but poses an unexpected problem: because the PIE is mapped directly below the stack, the stack cannot grow anymore, and the only free stack space is the initial stack expansion (128KB) minus the argv[] and envp[] pointers (which are stored there, as mentioned in II.3.2.):
-
on the one hand, many argv[] and envp[] pointers, and hence many argument and environment strings, result in a higher probability of mapping the PIE directly below the stack;
-
on the other hand, many argv[] and envp[] pointers consume most of the initial stack expansion and do not leave enough free stack space for ld.so to operate.
In practice, we pass 96KB of argv[] pointers to execve(), thus leaving 32KB of free stack space for ld.so, and since the size of a pointer is 8B, and the maximum size of an argument string is 128KB, we also pass 96KB/8B*128KB=1.5GB of argument strings to execve(). The resulting probability of mapping the PIE directly below the stack is:
SUM(s = 0; s < 1.5GB - 128MB; s++) s / (16GB * 1TB)
~= ((1.5GB - 128MB)^2 / 2) / (16GB * 1TB)
~= 1 / 17331
On a 4GB Virtual Machine, each run takes 1 second, and 17331 runs take roughly 5 hours. But we cannot add more uncertainty to this exploit, and because of the problems discussed in IV.1.4. (null-bytes in DT_NEEDED, but also in DT_AUXILIARY on 64-bit, etc), we were unable to overwrite the .dynamic section with a pattern that does not significantly decrease this exploit's probability of success.
All kernels, ld.so "hwcap" exploit
Despite this failure, we had an intuition: when the PIE is mapped directly below the stack, the stack layout should be deterministic -- rsp should point into the 128KB of initial stack expansion, at a 32KB offset above the start of the stack, and the only entropy should be the 8KB of sub-page randomization within the stack (arch_align_stack() in arch/x86/kernel/process.c). The following output of our small test program confirmed this intuition (the fourth field is the distance between the start of the stack and our main()'s rsp when the PIE is mapped directly below the stack):
$ grep -w sp test64.out | sort -nk4 sp 0x7ffbc271ff38 -> 28472 sp 0x7ffbb95ccff8 -> 28664 sp 0x7ffbaf062678 -> 30328 sp 0x7ffbb08736e8 -> 30440 sp 0x7ffbbc616d18 -> 32024 sp 0x7ffbc1a0fdb8 -> 32184 sp 0x7ffbb9c28ff8 -> 32760 sp 0x7ffbdbf4c178 -> 33144 sp 0x7ffbb39bc1c8 -> 33224 sp 0x7ffbebb86838 -> 34872
Surprisingly, the output of this test program contained additional valuable information:
7ffbb7e51000-7ffbb7e53000 r-xp 00000000 fd:03 4465810 /tmp/test64 7ffbb8034000-7ffbb8037000 rw-p 00000000 00:00 0 7ffbb804d000-7ffbb804e000 rw-p 00000000 00:00 0 7ffbb804e000-7ffbb8050000 r--p 00000000 00:00 0 [vvar] 7ffbb8050000-7ffbb8052000 r-xp 00000000 00:00 0 [vdso] 7ffbb8052000-7ffbb8053000 r--p 00001000 fd:03 4465810 /tmp/test64 7ffbb8053000-7ffbb808c000 rw-p 00002000 fd:03 4465810 /tmp/test64 7ffbb808d000-7ffc180ae000 rw-p 00000000 00:00 0 [heap] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
- the distance between the end of the read-execute segment of our test program and the start of its read-only and read-write segments is approximately 2MB; indeed, for every ELF on amd64:
$ readelf -a /usr/bin/su | grep -wA1 LOAD LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x00000000000061b4 0x00000000000061b4 R E 200000 LOAD 0x0000000000006888 0x0000000000206888 0x0000000000206888 0x0000000000000798 0x00000000000007d0 RW 200000
$ readelf -a /lib64/ld-linux-x86-64.so.2 | grep -wA1 LOAD LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x000000000001fad0 0x000000000001fad0 R E 200000 LOAD 0x000000000001fb60 0x000000000021fb60 0x000000000021fb60 0x000000000000141c 0x00000000000015e8 RW 200000
- several objects are actually mapped inside this ~2MB hole: [vdso], [vvar], and two anonymous mappings (7ffbb804d000-7ffbb804e000 and 7ffbb8034000-7ffbb8037000).
This discovery allowed us to adapt our ld.so "hwcap" exploit to amd64:
-
we choose hardware-capabilities that are small enough to be mapped inside this ~2MB hole, but large enough to defeat the 8KB sub-page randomization of the stack;
-
we jump over the stack guard-page, and over the read-only and read-write segments of the PIE, and exploit ld.so as we did on i386.
This exploit's probability of success is therefore 1 when the PIE is mapped directly below the stack, and its final probability of success is ~1/17331: it takes 1 second per run, and has a good chance of obtaining a root-shell after 5 hours. Moreover, it works on all kernels: if a SUID binary is not a PIE, or if the kernel is not vulnerable to offset2lib, we simply jump over ld.so's read-write segment, instead of the PIE's. For example, on Fedora 25, when the exploit succeeds and loads our own library /var/tmp/a (the 7ffbabbef000-7ffbabca7000 mapping contains the hardware-capabilities that we smash):
55a0c9e8d000-55a0c9e91000 r-xp 00000000 fd:00 112767 /usr/libexec/cockpit-polkit 55a0ca091000-55a0ca093000 rw-p 00004000 fd:00 112767 /usr/libexec/cockpit-polkit 7ffbab603000-7ffbab604000 r-xp 00000000 fd:00 4866583 /var/tmp/a 7ffbab604000-7ffbab803000 ---p 00001000 fd:00 4866583 /var/tmp/a 7ffbab803000-7ffbab804000 r--p 00000000 fd:00 4866583 /var/tmp/a 7ffbab804000-7ffbaba86000 rw-p 00000000 00:00 0 7ffbaba86000-7ffbabaab000 r-xp 00000000 fd:00 4229637 /usr/lib64/ld-2.24.so 7ffbabbef000-7ffbabca7000 rw-p 00000000 00:00 0 7ffbabca7000-7ffbabca9000 r--p 00000000 00:00 0 [vvar] 7ffbabca9000-7ffbabcab000 r-xp 00000000 00:00 0 [vdso] 7ffbabcab000-7ffbabcad000 rw-p 00025000 fd:00 4229637 /usr/lib64/ld-2.24.so 7ffbabcad000-7ffbabcae000 rw-p 00000000 00:00 0 7ffbabcaf000-7ffc0bcf0000 rw-p 00000000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
======================================================================== IV.2. OpenBSD ========================================================================
======================================================================== IV.2.1. Maximum RLIMIT_STACK vulnerability (CVE-2017-1000372) ========================================================================
The OpenBSD kernel limits the maximum size of the user-space stack (RLIMIT_STACK) to MAXSSIZ (32MB); the execve() system-call allocates a MAXSSIZ memory region for the stack and divides it in two:
-
the second part, effectively the user-space stack, is mapped PROT_READ|PROT_WRITE at the end of this stack memory region, and occupies RLIMIT_STACK bytes (by default 8MB for root processes, and 4MB for user processes);
-
the first part, effectively a large stack guard-page, is mapped PROT_NONE at the start of this stack memory region, and occupies MAXSSIZ - RLIMIT_STACK bytes.
Unfortunately, we discovered that if an attacker sets RLIMIT_STACK to MAXSSIZ, he eliminates the PROT_NONE part of the stack region, and hence the stack guard-page itself (CVE-2017-1000372). For example:
sh -c 'ulimit -S -s; procmap -a -P'
8192 Start End Size Offset rwxpc RWX I/W/A Dev Inode - File ... 14cf6000-14cfafff 20k 00000000 r-xp+ (rwx) 1/0/0 00:03 52375 - /usr/sbin/procmap [0xdb29ce10] ... 84a7b000-84a7bfff 4k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ anon ] cd7db000-cefdafff 24576k 00000000 ---p+ (rwx) 1/0/0 00:00 0 - [ stack ] cefdb000-cf7cffff 8148k 00000000 rw-p+ (rwx) 1/0/0 00:00 0 - [ stack ] cf7d0000-cf7dafff 44k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ stack ] total 10348k
sh -c 'ulimit -S -s ulimit -H -s
; procmap -a -P'
Start End Size Offset rwxpc RWX I/W/A Dev Inode - File ... 1a47f000-1a483fff 20k 00000000 r-xp+ (rwx) 1/0/0 00:03 52375 - /usr/sbin/procmap [0xdb29ce10] ... 8a3c8000-8a3c9fff 8k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ anon ] cd7c9000-cf7bffff 32732k 00000000 rw-p+ (rwx) 1/0/0 00:00 0 - [ stack ] cf7c0000-cf7c8fff 36k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ stack ] total 33992k
A remote attacker cannot exploit this vulnerability, because he cannot modify RLIMIT_STACK; but a local attacker can set RLIMIT_STACK to MAXSSIZ, and:
-
Step 1: malloc()ate almost 2GB of heap memory, until the heap reaches the start of the stack region;
-
Steps 2 and 3: consume MAXSSIZ (32MB) of stack memory, until the stack-pointer reaches the start of the stack region (Step 2) and moves into the heap (Step 3);
-
Step 4: smash the stack with the heap (Step 4a) or smash the heap with the stack (Step 4b).
======================================================================== IV.2.2. Recursive qsort() vulnerability (CVE-2017-1000373) ========================================================================
To complete Step 2, a recursive function is needed, and the first possibly recursive function that we investigated is qsort(). On the one hand, glibc's _quicksort() function (in stdlib/qsort.c) is non-recursive (iterative): it uses a small, specialized stack of partition structures (two pointers, low and high), and guarantees that no more than 32 partitions (on i386) or 64 partitions (on amd64) are pushed onto this stack, because it always pushes the larger of two sub-partitions and iterates on the smaller partition.
On the other hand, BSD's qsort() function is recursive: it always recurses on the first sub-partition, and iterates on the second sub-partition; but instead, it should always recurse on the smaller sub-partition, and iterate on the larger sub-partition (CVE-2017-1000373 in OpenBSD, CVE-2017-1000378 in NetBSD, and CVE-2017-1082 in FreeBSD).
In theory, because BSD's qsort() is not randomized, an attacker can construct a pathological input array of N elements that causes qsort() to deterministically recurse N times. In practice, because this qsort() uses the median-of-three medians-of-three selection of a pivot element (the "ninther"), our attack constructs an input array of N elements that causes qsort() to recurse N/4 times.
======================================================================== IV.2.3. /usr/bin/at proof-of-concept ========================================================================
/usr/bin/at is SGID-crontab (which can be escalated to full root privileges) because it must be able to create ("at -t"), list ("at -l"), and remove ("at -r") job-files in the /var/cron/atjobs directory:
-r-xr-sr-x 4 root crontab 31376 Jul 26 2016 /usr/bin/at drwxrwx--T 2 root crontab 512 Jul 26 2016 /var/cron/atjobs
To demonstrate that OpenBSD's RLIMIT_STACK and qsort() vulnerabilities can be transformed into powerful primitives such as heap corruption, we developed a proof-of-concept against "at -l" (the list_jobs() function):
-
Step 1 (Clash): first, list_jobs() malloc()ates an atjob structure for each file in /var/cron/atjobs -- if we create 40M job-files, then the heap reaches the stack, but we do not exhaust the address-space;
-
Steps 2 and 3 (Run and Jump): second, list_jobs() qsort()s the malloc()ated jobs -- if we construct their time-stamps with our qsort() attack, then we can cause qsort() to recurse 40M/4=10M times and consume at least 10M*4B=40MB of stack memory (each recursive call to qsort() consumes at least 4B, the return-address) and move the stack-pointer into the heap;
-
Step 4b (Smash the heap with the stack): last, list_jobs() free()s the malloc()ated jobs, and abort()s with an error message -- OpenBSD's hardened malloc() implementation detects that the heap has been corrupted by the last recursive calls to qsort().
This naive version of our /usr/bin/at proof-of-concept poses two major problems:
- Our pathological input array of N=40M elements cannot be sorted (Step 2 never finishes because it exhibits qsort()'s worst-case behavior, N^2). To solve this problem, we divide the input array in two:
. the first, pathological part contains only n=(33MB/176B)4=768K elements that are needed to complete Steps 2 and 3, and cause qsort() to recurse n/4 times and consume (n/4)176B=33MB of stack memory (MAXSSIZ+1MB) as each recursive call to qsort() consumes 176B of stack memory;
. the second, innocuous part contains the remaining N-n=39M elements that are needed to complete Step 1, but not Steps 2 and 3, and are therefore swapped into the second, iterative partition of the first recursive call to qsort().
- We were unable to create 40M files in /var/cron/atjobs: after one week, OpenBSD's default filesystem (ffs) had created only 4M files, and the rate of file creation had dropped from 25 files/second to 4 files/second. We did not solve this problem, but nevertheless wanted to validate our proof-of-concept:
. we transformed it into an LD_PRELOAD library that intercepts calls to readdir() and fstatat(), and pretends that our 40M files in /var/cron/atjobs exist;
. we made /var/cron/atjobs world-readable and LD_PRELOADed our library into a non-SGID copy of /usr/bin/at;
. after about an hour, "at" reports random heap corruptions:
chmod o+r /var/cron/atjobs
chmod o+r /var/cron/at.deny
$ ulimit -c 0
$ ulimit -S -d ulimit -H -d
$ ulimit -S -s ulimit -H -s
$ ulimit -S -a
...
coredump(blocks) 0
data(kbytes) 3145728
stack(kbytes) 32768
...
$ cp /usr/bin/at .
$ LD_PRELOAD=./OpenBSD_at.so ./at -l -v -q x > /dev/null initializing jobkeys finalizing jobkeys reading jobs 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% sorting jobs at(78717) in free(): error: chunk info corrupted Abort trap
$ LD_PRELOAD=./OpenBSD_at.so ./at -l -v -q x > /dev/null initializing jobkeys finalizing jobkeys reading jobs 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% sorting jobs at(14184) in free(): error: modified chunk-pointer 0xcd6d0120 Abort trap
======================================================================== IV.3. NetBSD ========================================================================
Like OpenBSD, NetBSD is vulnerable to the maximum RLIMIT_STACK vulnerability (CVE-2017-1000374): if a local attacker sets RLIMIT_STACK to MAXSSIZ, he eliminates the PROT_NONE part of the stack region -- the stack guard-page itself. Unlike OpenBSD, however, NetBSD:
-
defines MAXSSIZ to 64MB on i386 (128MB on amd64);
-
maps the run-time link-editor ld.so directly below the stack region, even if ASLR is enabled (CVE-2017-1000375):
$ sh -c 'ulimit -S -s; pmap -a -P' 2048 Start End Size Offset rwxpc RWX I/W/A Dev Inode - File 08048000-0804dfff 24k 00000000 r-xp+ (rwx) 1/0/0 00:00 21706 - /usr/bin/pmap [0xc5c8f0b8] ... bbbee000-bbbfefff 68k 00000000 r-xp+ (rwx) 1/0/0 00:00 107525 - /libexec/ld.elf_so [0xc535f580] bbbff000-bbbfffff 4k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ anon ] bbc00000-bf9fffff 63488k 00000000 ---p+ (rwx) 1/0/0 00:00 0 - [ stack ] bfa00000-bfbeffff 1984k 00000000 rw-p+ (rwx) 1/0/0 00:00 0 - [ stack ] bfbf0000-bfbfffff 64k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ stack ] total 9528k
$ sh -c 'ulimit -S -s ulimit -H -s
; pmap -a -P'
Start End Size Offset rwxpc RWX I/W/A Dev Inode - File
08048000-0804dfff 24k 00000000 r-xp+ (rwx) 1/0/0 00:00 21706 - /usr/bin/pmap [0xc5c8f0b8]
...
bbbee000-bbbfefff 68k 00000000 r-xp+ (rwx) 1/0/0 00:00 107525 - /libexec/ld.elf_so [0xc535f580]
bbbff000-bbbfffff 4k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ anon ]
bbc00000-bfbeffff 65472k 00000000 rw-p+ (rwx) 1/0/0 00:00 0 - [ stack ]
bfbf0000-bfbfffff 64k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ stack ]
total 73016k
cp /usr/bin/pmap .
paxctl +A ./pmap
sh -c 'ulimit -S -s ulimit -H -s
; ./pmap -a -P'
Start End Size Offset rwxpc RWX I/W/A Dev Inode - File 08048000-0804dfff 24k 00000000 r-xp+ (rwx) 1/0/0 00:00 172149 - /tmp/pmap [0xc5cb3c64] ... bbbee000-bbbfefff 68k 00000000 r-xp+ (rwx) 1/0/0 00:00 107525 - /libexec/ld.elf_so [0xc535f580] bbbff000-bbbfffff 4k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ anon ] bbc00000-bf1bffff 55040k 00000000 rw-p+ (rwx) 1/0/0 00:00 0 - [ stack ] bf1c0000-bf1cefff 60k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ stack ] total 62580k
Consequently, a local attacker can set RLIMIT_STACK to MAXSSIZ, eliminate the stack guard-page, and:
-
skip Step 1, because ld.so's read-write segment is naturally mapped directly below the stack region;
-
Steps 2 and 3: consume 64MB (MAXSSIZ) of stack memory (for example, through the recursive qsort() vulnerability, CVE-2017-1000378) until the stack-pointer reaches the start of the stack region (Step 2) and moves into ld.so's read-write segment (Step 3);
-
Step 4b: smash ld.so's read-write segment with the stack.
We did not try to exploit this vulnerability, nor did we search for a vulnerable SUID or SGID binary, but we wrote a simple proof-of-concept, and some of the following crashes may be exploitable:
$ sh -c 'ulimit -S -s ulimit -H -s
; ./NetBSD_CVE-2017-1000375 0x04000000'
[1] Segmentation fault ./NetBSD_CVE-201...
$ sh -c 'ulimit -S -s ulimit -H -s
; ./NetBSD_CVE-2017-1000375 0x03000000'
...
$ sh -c 'ulimit -S -s ulimit -H -s
; ./NetBSD_CVE-2017-1000375 0x03ec5000'
$ sh -c 'ulimit -S -s ulimit -H -s
; ./NetBSD_CVE-2017-1000375 0x03ec5400'
[1] Segmentation fault ./NetBSD_CVE-201...
$ sh -c 'ulimit -S -s ulimit -H -s
; gdb ./NetBSD_CVE-2017-1000375'
GNU gdb (GDB) 7.7.1
...
(gdb) run 0x03ec5400
Program received signal SIGSEGV, Segmentation fault.
0xbbbf448d in _rtld_symlook_default () from /usr/libexec/ld.elf_so
(gdb) x/i $eip
=> 0xbbbf448d <_rtld_symlook_default+185>: mov %edx,(%esi,%edi,4)
(gdb) info registers
esi 0xbabae890 -1162155888
edi 0x0 0
...
(gdb) run 0x03ec5800
Program received signal SIGSEGV, Segmentation fault.
0xbbbf4465 in _rtld_symlook_default () from /usr/libexec/ld.elf_so
(gdb) x/i $eip
=> 0xbbbf4465 <_rtld_symlook_default+145>: mov 0x4(%ecx),%edx
(gdb) info registers
ecx 0x41414141 1094795585
...
(gdb) run 0x03ec5c00
Program received signal SIGSEGV, Segmentation fault.
0xbbbf4408 in _rtld_symlook_default () from /usr/libexec/ld.elf_so
(gdb) x/i $eip
=> 0xbbbf4408 <_rtld_symlook_default+52>: mov (%eax),%esi
(gdb) info registers
eax 0x41414141 1094795585
...
======================================================================== IV.4. FreeBSD ========================================================================
======================================================================== IV.4.1. setrlimit() RLIMIT_STACK vulnerability (CVE-2017-1085) ========================================================================
FreeBSD's kern_proc_setrlimit() function contains the following comment and code:
/*
* Stack is allocated to the max at exec time with only
* "rlim_cur" bytes accessible. If stack limit is going
* up make more accessible, if going down make inaccessible.
*/
if (limp->rlim_cur != oldssiz.rlim_cur) {
...
if (limp->rlim_cur > oldssiz.rlim_cur) {
prot = p->p_sysent->sv_stackprot;
size = limp->rlim_cur - oldssiz.rlim_cur;
addr = p->p_sysent->sv_usrstack -
limp->rlim_cur;
} else {
prot = VM_PROT_NONE;
size = oldssiz.rlim_cur - limp->rlim_cur;
addr = p->p_sysent->sv_usrstack -
oldssiz.rlim_cur;
}
...
(void)vm_map_protect(&p->p_vmspace->vm_map,
addr, addr + size, prot, FALSE);
}
OpenBSD's and NetBSD's dosetrlimit() function contains the same comment, which accurately describes the layout of their user-space stack region. Unfortunately, FreeBSD's kern_proc_setrlimit() comment and code are incorrect, as hinted at in exec_new_vmspace():
/ * Destroy old address space, and allocate a new stack * The new stack is only SGROWSIZ large because it is grown * automatically in trap.c. /
and vm_map_stack_locked():
/*
* We initially map a stack of only init_ssize. We will grow as
* needed later.
where init_ssize is SGROWSIZ (128KB), not MAXSSIZ (64MB on i386), because "init_ssize = (max_ssize < growsize) ? max_ssize : growsize;" (and max_ssize is MAXSSIZ, and growsize is SGROWSIZ).
As a result, if a program calls setrlimit() to increase RLIMIT_STACK, vm_map_protect() may turn a read-only memory region below the stack into a read-write region (CVE-2017-1085), as demonstrated by the following proof-of-concept:
% ./FreeBSD_CVE-2017-1085 Segmentation fault
% ./FreeBSD_CVE-2017-1085 setrlimit to the max char at 0xbd155000: 41
======================================================================== IV.4.2. Stack guard-page disabled by default (CVE-2017-1083) ========================================================================
The FreeBSD kernel implements a 4KB stack guard-page, and recent versions of the FreeBSD Installer offer it as a system hardening option. Unfortunately, it is disabled by default (CVE-2017-1083):
% sysctl security.bsd.stack_guard_page security.bsd.stack_guard_page: 0
======================================================================== IV.4.3. Stack guard-page vulnerabilities (CVE-2017-1084) ========================================================================
- If FreeBSD's stack guard-page is enabled, its entire logic is implemented in vm_map_growstack(): this function guarantees a minimum distance of 4KB (the stack guard-page) between the start of the stack and the end of the memory region that is mapped below (but the stack guard-page is not physically mapped into the address-space).
Unfortunately, this guarantee is given only when the stack grows down and clashes with the memory region mapped below, but not if the memory region mapped below grows up and clashes with the stack: this vulnerability effectively eliminates the stack guard-page (CVE-2017-1084). In our proof-of-concept:
. we allocate anonymous mmap()s of 4KB, until the end of an anonymous mmap() reaches the start of the stack [Step 1];
. we call a recursive function until the stack-pointer reaches the start of the stack and moves into the anonymous mmap() directly below [Step 2];
. but we do not jump over the stack guard-page, because each call to the recursive function allocates (and fully writes to) a 1KB stack-based buffer [Step 3];
. and we do not crash into the stack guard-page, because CVE-2017-1084 has effectively eliminated the stack guard-page in Step 1.
sysctl security.bsd.stack_guard_page=1
security.bsd.stack_guard_page: 0 -> 1
% ./FreeBSD_CVE-2017-FGPU char at 0xbfbde000: 41
- vm_map_growstack() implements most of the stack guard-page logic in
the following code:
/* * Growing downward. */ /* Get the preliminary new entry start value */ addr = stack_entry->start - grow_amount; /* * If this puts us into the previous entry, cut back our * growth to the available space. Also, see the note above. */ if (addr < end) { stack_entry->avail_ssize = max_grow; addr = end; if (stack_guard_page) addr += PAGE_SIZE; }
where:
. addr is the new start of the stack;
. stack_entry->start is the old start of the stack;
. grow_amount is the size of the stack expansion;
. end is the end of the memory region below the stack.
Unfortunately, the "addr < end" test should be "addr <= end": if addr, the new start of the stack, is equal to end, the end of the memory region mapped below, then the stack guard-page is eliminated (CVE-2017-1084). In our proof-of-concept:
. we allocate anonymous mmap()s of 4KB, until the end of an anonymous mmap() reaches a randomly chosen distance below the start of the stack [Step 1];
. we call a recursive function until the stack-pointer reaches the start of the stack, and the stack expansion reaches the end of the anonymous mmap() below [Step 2];
. we do not jump over the stack guard-page, because each call to the recursive function allocates (and fully writes to) a 1KB stack-based buffer [Step 3];
. and we crash into the stack guard-page most of the time;
. but we survive with a probability of 4KB/128KB=1/32 (grow_amount is always a multiple of SGROWSIZ, 128KB) because CVE-2017-1084 has effectively eliminated the stack guard-page in Step 2.
% sysctl security.bsd.stack_guard_page security.bsd.stack_guard_page: 1
% sh -c 'while true; do ./FreeBSD_CVE-2017-FGPE; done' Segmentation fault char at 0xbe45e000: 41; final dist 6097 (24778705) Segmentation fault Segmentation fault Segmentation fault ... Segmentation fault Segmentation fault Segmentation fault char at 0xbd25e000: 41; final dist 7036 (43654012) Segmentation fault Segmentation fault Segmentation fault ... Segmentation fault Segmentation fault Segmentation fault char at 0xbd29e000: 41; final dist 5331 (43390163) Segmentation fault Segmentation fault Segmentation fault ...
In contrast, if FreeBSD's stack guard-page is disabled, our proof-of-concept always survives:
sysctl security.bsd.stack_guard_page=0
security.bsd.stack_guard_page: 1 -> 0
% sh -c 'while true; do ./FreeBSD_CVE-2017-FGPE; done' char at 0xbe969000: 41; final dist 89894 (19488550) char at 0xbfa6d000: 41; final dist 74525 (1647389) char at 0xbf4df000: 41; final dist 78 (7471182) char at 0xbe9e4000: 41; final dist 112397 (18986765) char at 0xbf693000: 41; final dist 49811 (5685907) char at 0xbf533000: 41; final dist 51037 (7128925) char at 0xbd799000: 41; final dist 26043 (38167995) char at 0xbd54b000: 11; final dist 83754 (40585002) char at 0xbe176000: 41; final dist 36992 (27824256) char at 0xbfa91000: 41; final dist 57449 (1499241) char at 0xbd1b9000: 41; final dist 26115 (44328451) char at 0xbd1c8000: 41; final dist 94852 (44266116) char at 0xbf73a000: 41; final dist 22276 (5003012) char at 0xbe6b1000: 41; final dist 58854 (22341094) char at 0xbeb81000: 41; final dist 124727 (17295159) char at 0xbfb35000: 41; final dist 43174 (829606) ...
- FreeBSD's thread library (libthr) mmap()s a secondary PROT_NONE stack guard-page at a distance RLIMIT_STACK below the end of the stack:
sysctl security.bsd.stack_guard_page=1
security.bsd.stack_guard_page: 0 -> 1
% sh -c 'exec procstat -v $$' PID START END PRT RES PRES REF SHD FLAG TP PATH 2779 0x8048000 0x8050000 r-x 8 8 1 0 CN-- vn /usr/bin/procstat ... 2779 0x28400000 0x28800000 rw- 22 35 2 0 ---- df 2779 0xbfbdf000 0xbfbff000 rwx 3 3 1 0 ---D df 2779 0xbfbff000 0xbfc00000 r-x 1 1 23 0 ---- ph
% sh -c 'LD_PRELOAD=libthr.so exec procstat -v $$' PID START END PRT RES PRES REF SHD FLAG TP PATH 2798 0x8048000 0x8050000 r-x 8 8 1 0 CN-- vn /usr/bin/procstat ... 2798 0x28400000 0x28800000 rw- 23 35 2 0 ---- df 2798 0xbbbfe000 0xbbbff000 --- 0 0 0 0 ---- -- 2798 0xbfbdf000 0xbfbff000 rwx 3 3 1 0 ---D df 2798 0xbfbff000 0xbfc00000 r-x 1 1 23 0 ---- ph
Unfortunately, this secondary stack guard-page does not mitigate the vulnerabilities that we discovered in FreeBSD's stack guard-page implementation:
% sysctl security.bsd.stack_guard_page security.bsd.stack_guard_page: 1
% sh -c 'LD_PRELOAD=libthr.so ./FreeBSD_CVE-2017-FGPU' char at 0xbfbde000: 41
% sh -c 'while true; do LD_PRELOAD=libthr.so ./FreeBSD_CVE-2017-FGPE; done' Segmentation fault Segmentation fault Segmentation fault ... Segmentation fault Segmentation fault Segmentation fault char at 0xbda5e000: 41; final dist 3839 (35262207) Segmentation fault Segmentation fault Segmentation fault ... Segmentation fault Segmentation fault Segmentation fault char at 0xbdb1e000: 41; final dist 3549 (34475485) Segmentation fault Segmentation fault Segmentation fault ...
======================================================================== IV.4.4. Remote exploitation ========================================================================
Because FreeBSD's stack guard-page is disabled by default, we tried (and failed) to remotely exploit a test service vulnerable to:
-
an unlimited memory leak that allows us to malloc()ate gigabytes of memory;
-
a limited recursion that allows us to allocate up to 1MB of stack memory.
FreeBSD's malloc() implementation (jemalloc) mmap()s 4MB chunks of anonymous memory that are aligned on multiples of 4MB. The first 4MB mmap() chunk starts at 0x28400000, and the last 4MB mmap() chunk ends at 0xbf800000, because the stack itself already ends at 0xbfc00000; but it is impossible to cover this final mmap-stack distance (almost 4MB) with the limited recursion (1MB) of our test service. break(0x80499b0) = 0 (0x0) break(0x8400000) = 0 (0x0) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 672845824 (0x281ad000) mmap(0x285ad000,2437120,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 677040128 (0x285ad000) munmap(0x281ad000,2437120) = 0 (0x0) mmap(0x0,8388608,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 679477248 (0x28800000) munmap(0x28c00000,4194304) = 0 (0x0) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 683671552 (0x28c00000) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 687865856 (0x29000000) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 692060160 (0x29400000) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 696254464 (0x29800000) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 700448768 (0x29c00000) ... mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = -1103101952 (0xbe400000) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = -1098907648 (0xbe800000) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = -1094713344 (0xbec00000) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = -1090519040 (0xbf000000) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = -1086324736 (0xbf400000) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) ERR#12 'Cannot allocate memory' break(0x8800000) = 0 (0x0) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) ERR#12 'Cannot allocate memory' break(0x8c00000) = 0 (0x0) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) ERR#12 'Cannot allocate memory' break(0x9000000) = 0 (0x0) ... mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) ERR#12 'Cannot allocate memory' break(0x27c00000) = 0 (0x0) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) ERR#12 'Cannot allocate memory' break(0x28000000) = 0 (0x0) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) ERR#12 'Cannot allocate memory' break(0x28400000) ERR#12 'Cannot allocate memory'
======================================================================== IV.5. Solaris >= 11.1 ========================================================================
======================================================================== IV.5.1. Minimal RLIMIT_STACK vulnerability (CVE-2017-3630) ========================================================================
On Solaris, ASLR can be enabled or disabled for each ELF binary with the SUNW_ASLR dynamic section entry (man elfedit):
$ elfdump /usr/bin/rsh | egrep 'ASLR|NX' [39] SUNW_ASLR 0x2 ENABLE [40] SUNW_NXHEAP 0x2 ENABLE [41] SUNW_NXSTACK 0x2 ENABLE
Without ASLR
If ASLR is disabled:
-
a stack region of size RLIMIT_STACK is reserved in the address-space;
-
a 4KB stack guard-page is mapped directly below this stack region;
-
the runtime linker ld.so is mapped directly below this stack guard-page.
$ cp /usr/bin/sleep . $ chmod u+w ./sleep $ elfedit -e 'dyn:sunw_aslr disable' ./sleep
$ sh -c 'ulimit -S -s; ./sleep 3 & pmap -r ${!}' 8192 7176: ./sleep 3 ... FE7B1000 228K r-x---- /lib/ld.so.1 FE7FA000 8K rwx---- /lib/ld.so.1 FE7FC000 8K rwx---- /lib/ld.so.1 FE7FF000 8192K rw----- [ stack ] total 17148K
$ sh -c 'ulimit -S -s 64; ./sleep 3 & pmap -r ${!}' 7244: ./sleep 3 ... FEFA1000 228K r-x---- /lib/ld.so.1 FEFEA000 8K rwx---- /lib/ld.so.1 FEFEC000 8K rwx---- /lib/ld.so.1 FEFEF000 64K rw----- [ stack ] total 9020K
On the one hand, a local attacker can exploit this simplified stack-clash:
-
Step 1 (Clash) is not needed, because ld.so is naturally mapped directly below the stack (the distance between the end of ld.so's read-write segment and the start of the stack is 4KB, the stack guard-page);
-
Step 2 (Run) is not needed, because a local attacker can set RLIMIT_STACK to just a few kilobytes, reserve a very small stack region, and hence shorten the distance between the stack-pointer and the start of the stack (and the end of ld.so's read-write segment);
-
Step 3 (Jump) can be completed with a large stack-based buffer that is not fully written to;
-
Step 4b (Smash) can be completed by overwriting the function pointers in ld.so's read-write segment with the contents of a stack-based buffer.
Such a simplified stack-clash exploit was first mentioned in Gael Delalleau's 2005 presentation (slide 30).
On the other hand, a remote attacker cannot modify RLIMIT_STACK and must complete Step 2 (Run) with a recursive function that consumes the 8MB (the default RLIMIT_STACK) between the stack-pointer and the start of the stack.
With ASLR
If ASLR is enabled:
-
a stack region of size RLIMIT_STACK is reserved in the address-space;
-
a 4KB stack guard-page is mapped directly below this stack region;
-
the runtime linker ld.so is mapped below this stack guard-page, but at a random distance (within a [4KB,128MB] range) -- effectively a large, secondary stack guard-page.
On the one hand, a local attacker can run the simplified "Without ASLR" stack-clash exploit until the ld.so-stack distance is minimal -- with a probability of 4KB/128MB=1/32K, the distance between the end of ld.so's read-write segment and the start of the stack is exactly 8KB: the stack guard-page plus the minimum distance between the stack guard-page and ld.so (CVE-2017-3629).
On the other hand, a remote attacker must complete Step 2 (Run) with a recursive function, and:
-
has a good chance of exploiting this stack-clash after 32K connections (when the ld.so-stack distance is minimal) if the remote service re-execve()s (re-randomizes the ld.so-stack distance for each new connection);
-
cannot exploit this stack-clash if the remote service does not re-execve() (does not re-randomize the ld.so-stack distance for each new connection) unless the attacker is able to restart the service, reboot the server, or target a 32K-server farm.
======================================================================== IV.5.2. /usr/bin/rsh exploit ========================================================================
/usr/bin/rsh is SUID-root and its main() function allocates a 50KB stack-based buffer that is not written to and can be used to jump over the stack guard-page, into ld.so's read-write segment, in Step 3 of our simplified stack-clash exploit.
Next, we discovered a general method for gaining eip control in Step 4b: setlocale(LC_ALL, ""), called by the main() function of /usr/bin/rsh and other SUID binaries, copies the LC_ALL environment variable to several stack-based buffers and thus smashes ld.so's read-write segment and overwrites some of ld.so's function pointers.
Last, we execute our own shell-code: we return-into-binary (/usr/bin/rsh is not a PIE), to an instruction that reliably jumps into a copy of our LC_ALL environment variable in ld.so's read-write segment, which is in fact read-write-executable. For example, after we gain control of eip:
-
on Solaris 11.1, we return to a "pop; pop; ret" instruction, because a pointer to our shell-code is stored at an 8-byte offset from esp;
-
on Solaris 11.3, we return to a "call *0xc(%ebp)" instruction, because a pointer to our shell-code is stored at a 12-byte offset from ebp.
Our Solaris exploit brute-forces the random ld.so-stack distance and two parameters:
-
the RLIMIT_STACK;
-
the length of the LC_ALL environment variable.
======================================================================== IV.5.3. Forced-Privilege vulnerability (CVE-2017-3631) ========================================================================
/usr/bin/rsh is SUID-root, but the shell that we obtained in Step 4b of our stack-clash exploit did not grant us full root privileges, only net_privaddr, the privilege to bind to a privileged port number. Disappointed by this result, we investigated and found:
$ ggrep -r /usr/bin/rsh /etc 2>/dev/null /etc/security/exec_attr.d/core-os:Forced Privilege:solaris:cmd:RO::/usr/bin/rsh:privs=net_privaddr
$ /usr/bin/rsh -h /usr/bin/rsh: illegal option -- h usage: rsh [ -PN / -PO ] [ -l login ] [ -n ] [ -k realm ] [ -a ] [ -x ] [ -f / -F ] host command rsh [ -PN / -PO ] [ -l login ] [ -k realm ] [ -a ] [ -x ] [ -f / -F ] host
cat truss.out
... 7319: execve("/usr/bin/rsh", 0xA9479C548, 0xA94792808) argc = 2 7319: *** FPRIV: P/E: net_privaddr *** ...
Unfortunately, this Forced-Privilege protection is based on the pathname of SUID-root binaries, which can be execve()d through hard-links, under different pathnames (CVE-2017-3631). For example, we discovered that readable SUID-root binaries can be execve()d through hard-links in /proc:
$ sleep 3 < /usr/bin/rsh & /proc/${!}/fd/0 -h [1] 7333 /proc/7333/fd/0: illegal option -- h usage: rsh [ -PN / -PO ] [ -l login ] [ -n ] [ -k realm ] [ -a ] [ -x ] [ -f / -F ] host command rsh [ -PN / -PO ] [ -l login ] [ -k realm ] [ -a ] [ -x ] [ -f / -F ] host
cat truss.out
... 7335: execve("/proc/7333/fd/0", 0xA947CA508, 0xA94792808) argc = 2 7335: *** SUID: ruid/euid/suid = 100 / 0 / 0 *** ...
This vulnerability allows us to bypass the Forced-Privilege protection and obtain full root privileges with our /usr/bin/rsh exploit.
======================================================================== V. Acknowledgments ========================================================================
We thank the members of the distros list, Oracle/Solaris, Exim, Sudo, security@kernel.org, grsecurity/PaX, and OpenBSD. SEC Consult Vulnerability Lab Security Advisory < 20190904-0 > ======================================================================= title: Multiple vulnerabilities product: Cisco RV340, Cisco RV340W, Cisco RV345, Cisco RV345P, Cisco RV260, Cisco RV260P, Cisco RV260W, Cisco 160, Cisco 160W vulnerable version: Cisco RV34X - 1.0.02.16, Cisco RV16X/26X - 1.0.00.15 fixed version: see "Solution" CVE number: - impact: High homepage: https://www.cisco.com/ found: 2019-05-15 by: T. Weber, S. Viehböck (Office Vienna) IoT Inspector SEC Consult Vulnerability Lab
An integrated part of SEC Consult
Europe | Asia | North America
https://www.sec-consult.com
=======================================================================
Vendor description:
"Securely connecting your small business to the outside world is as important as connecting your internal network devices to one another. Cisco Small Business RV Series Routers offer virtual private networking (VPN) technology so your remote workers can connect to your network through a secure Internet pathway."
Source: https://www.cisco.com/c/en/us/products/routers/small-business-rv-series-routers/index.html
Business recommendation:
We want to thank Cisco for the very quick and professional response and great coordination. Customers are urged to update the firmware of their devices.
Vulnerability overview/description:
1) Hardcoded Credentials The device contains hardcoded users and passwords which can be used to login via SSH on an emulated device at least.
During the communication with Cisco it turned out that: "Accounts like the 'debug-admin' and 'root' can not be accessed from console port, CLI or webui". Therefore, these accounts had no real functionality and cannot be used for malicious actions.
2) Known GNU glibc Vulnerabilities The used GNU glibc in version 2.19 is outdated and contains multiple known vulnerabilities. The outdated version was found by IoT Inspector. One of the discovered vulnerabilities (CVE-2015-7547, "getaddrinfo() buffer overflow") was verified by using the MEDUSA scalable firmware runtime.
3) Known BusyBox Vulnerabilities The used BusyBox toolkit in version 1.23.2 is outdated and contains multiple known vulnerabilities. The outdated version was found by IoT Inspector. One of the discovered vulnerabilities (CVE-2017-16544) was verified by using the MEDUSA scaleable firmware runtime.
4) Multiple Vulnerabilities - IoT Inspector Report Further information can be found in IoT Inspector report: https://r.sec-consult.com/ciscoiot
Proof of concept:
1) Hardcoded Credentials The following hardcoded hashes were found in the 'shadow' file of the firmware: root:$1$hPNSjUZA$7eKqEpqVYltt9xJ6f0OGf0:15533:0:99999:7::: debug-admin:$1$.AAm0iJ4$na9wZwly9pSrdS8MhcGKw/:15541:0:99999:7::: [...]
The undocumented user 'debug-admin' is also contained in this file.
Starting the dropbear daemon as background process on emulated firmware:
dropbear -E
[1109] Running in background
[1112] Child connection from :52718
[1112]
Log on via another host connected to the same network. For this PoC the password of the debug-admin was changed in the 'shadow' file.
[root@localhost medusa]# ssh debug-admin@
BusyBox v1.23.2 (2018-11-21 18:22:56 IST) built-in shell (ash)
/tmp $
The 'debug-admin' user has the same privileges like 'root'. This can be determined from the corresponding sudoers file in the firmware: [...]
User privilege specification
root ALL=(ALL) ALL debug-admin ALL=(ALL) ALL
Uncomment to allow members of group wheel to execute any command
%wheel ALL=(ALL) ALL
[...]
During the communication with Cisco it turned out that: "Accounts like the 'debug-admin' and 'root' can not be accessed from console port, CLI or webui". Therefore, these accounts had no real functionality and cannot be used for malicious actions.
2) Known GNU glibc Vulnerabilities GNU glibc version 2.19 contains multiple CVEs like: CVE-2014-4043, CVE-2014-9402, CVE-2014-9761, CVE-2014-9984, CVE-2015-1472, CVE-2015-5277, CVE-2015-8778, CVE-2015-8779, CVE-2017-1000366 and more.
The getaddrinfo() buffer overflow vulnerability was checked with the help of the exploit code from https://github.com/fjserna/CVE-2015-7547. It was compiled and executed on the emulated device to test the system.
python cve-2015-7547-poc.py &
[1] 961
chroot /medusa_rootfs/ bin/ash
BusyBox v1.23.2 (2018-11-21 18:22:56 IST) built-in shell (ash)
gdb cve-2015-7547_glibc_getaddrinfo
[...] [UDP] Total Data len recv 36 [UDP] Total Data len recv 36 Connected with 127.0.0.1:41782 [TCP] Total Data len recv 76 [TCP] Request1 len recv 36 [TCP] Request2 len recv 36 Cannot access memory at address 0x4
Program received signal SIGSEGV, Segmentation fault. 0x76f1fd58 in ?? () from /lib/libc.so.6 (gdb)
References: https://security.googleblog.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html https://github.com/fjserna/CVE-2015-7547
3) Known BusyBox Vulnerabilities BusyBox version 1.23.2 contains multiple CVEs like: CVE-2016-2148, CVE-2016-6301, CVE-2015-9261, CVE-2016-2147, CVE-2018-20679, CVE-2017-16544 and CVE-2019-5747. The BusyBox shell autocompletion vulnerability (CVE-2017-16544) was verified on an emulated device:
A file with the name "\ectest\n\e]55;test.txt\a" was created to trigger the vulnerability.
ls "pressing "
test ]55;test.txt
4) Multiple Vulnerabilities - IoT Inspector Report Further information can be found in IoT Inspector report: https://r.sec-consult.com/ciscoiot
The summary is below: IoT Inspector Vulnerability #1 BusyBox CVE entries Outdated BusyBox version is affected by 7 published CVEs.
IoT Inspector Vulnerability #2 curl CVE entries Outdated curl version is affected by 35 published CVEs.
IoT Inspector Vulnerability #3 GNU glibc CVE entries Outdated GNU glibc version is affected by 44 published CVEs.
IoT Inspector Vulnerability #4 GNU glibc getaddrinfo() buffer overflow Outdated GNU glibc version is affected by CVE-2015-7547.
IoT Inspector Vulnerability #5 Hardcoded password hashes Firmware contains multiple hardcoded credentials.
IoT Inspector Vulnerability #6 Linux Kernel CVE entries Outdated Linux Kernel version affected by 512 published CVEs.
IoT Inspector Vulnerability #7 MiniUPnPd CVE entries Outdated MiniUPnPd version affected by 2 published CVEs.
IoT Inspector Vulnerability #8 Dnsmasq CVE entries Outdated MiniUPnPd version affected by 1 published CVE.
IoT Inspector Vulnerability #9 Linux Kernel Privilege Escalation “pp_key” Outdated Linux Kernel version is affected by CVE-2015-7547.
IoT Inspector Vulnerability #10 OpenSSL CVE entries Outdated OpenSSL version affected by 6 published CVEs.
Vulnerable / tested versions:
The following firmware versions have been tested with IoT Inspector and firmware emulation techniques: Cisco RV340 / 1.0.02.16 Cisco RV340W / 1.0.02.16 Cisco RV345 / 1.0.02.16 Cisco RV345P / 1.0.02.16 The following firmware versions have been tested with IoT Inspector only: Cisco RV260 / 1.0.00.15 Cisco RV260P / 1.0.00.15 Cisco RV260W / 1.0.00.15 Cisco RV160 / 1.0.00.15 Cisco RV160P / 1.0.00.15
The firmware was obtained from the vendor website: https://software.cisco.com/download/home/286287791/type/282465789/release/1.0.02.16 https://software.cisco.com/download/home/286316464/type/282465789/release/1.0.00.15
Vendor contact timeline:
2019-05-15: Contacting vendor through psirt@cisco.com. 2019-05-16: Vendor confirmed the receipt. 2019-05-2019-08: Periodic updates about the investigation from the vendor. Clarification which of the reported issues will be fixed. 2019-08-20: The vendor proposed the next possible publication date for the advisory for 2019-09-04. The vendor added the RV160 and RV260 router series to be vulnerable to the same issues too. 2019-09-04: Coordinated advisory release.
Solution:
Upgrade to the newest available firmware version.
Additionally, the vendor provides the following security notice: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190904-sb-vpnrouter
Workaround:
None.
Advisory URL:
https://www.sec-consult.com/en/vulnerability-lab/advisories/index.html
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SEC Consult Vulnerability Lab
SEC Consult Europe | Asia | North America
About SEC Consult Vulnerability Lab The SEC Consult Vulnerability Lab is an integrated part of SEC Consult. It ensures the continued knowledge gain of SEC Consult in the field of network and application security to stay ahead of the attacker. The SEC Consult Vulnerability Lab supports high-quality penetration testing and the evaluation of new offensive and defensive technologies for our customers. Hence our customers obtain the most current information about vulnerabilities and valid recommendation about the risk profile of new technologies.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Interested to work with the experts of SEC Consult? Send us your application https://www.sec-consult.com/en/career/index.html
Interested in improving your cyber security with the experts of SEC Consult? Contact our local offices https://www.sec-consult.com/en/contact/index.html ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mail: research at sec-consult dot com Web: https://www.sec-consult.com Blog: http://blog.sec-consult.com Twitter: https://twitter.com/sec_consult
EOF T. Weber / @2019
Show details on source website{ "@context": { "@vocab": "https://www.variotdbs.pl/ref/VARIoTentry#", "affected_products": { "@id": "https://www.variotdbs.pl/ref/affected_products" }, "configurations": { "@id": "https://www.variotdbs.pl/ref/configurations" }, "credits": { "@id": "https://www.variotdbs.pl/ref/credits" }, "cvss": { "@id": "https://www.variotdbs.pl/ref/cvss/" }, "description": { "@id": "https://www.variotdbs.pl/ref/description/" }, "exploit_availability": { "@id": "https://www.variotdbs.pl/ref/exploit_availability/" }, "external_ids": { "@id": "https://www.variotdbs.pl/ref/external_ids/" }, "iot": { "@id": "https://www.variotdbs.pl/ref/iot/" }, "iot_taxonomy": { "@id": "https://www.variotdbs.pl/ref/iot_taxonomy/" }, "patch": { "@id": "https://www.variotdbs.pl/ref/patch/" }, "problemtype_data": { "@id": "https://www.variotdbs.pl/ref/problemtype_data/" }, "references": { "@id": "https://www.variotdbs.pl/ref/references/" }, "sources": { "@id": "https://www.variotdbs.pl/ref/sources/" }, "sources_release_date": { "@id": "https://www.variotdbs.pl/ref/sources_release_date/" }, "sources_update_date": { "@id": "https://www.variotdbs.pl/ref/sources_update_date/" }, "threat_type": { "@id": "https://www.variotdbs.pl/ref/threat_type/" }, "title": { "@id": "https://www.variotdbs.pl/ref/title/" }, "type": { "@id": "https://www.variotdbs.pl/ref/type/" } }, "@id": "https://www.variotdbs.pl/vuln/VAR-201706-0334", "affected_products": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/affected_products#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" }, "@id": "https://www.variotdbs.pl/ref/sources" } }, "data": [ { "model": "linux enterprise software development kit", "scope": "eq", "trust": 1.6, "vendor": "suse", "version": "11.0" }, { "model": "enterprise linux workstation", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "6.0" }, { "model": "linux", "scope": "eq", "trust": 1.0, "vendor": "debian", "version": "8.0" }, { "model": "linux enterprise for sap", "scope": "eq", "trust": 1.0, "vendor": "suse", "version": "12" }, { "model": "enterprise linux server tus", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "6.6" }, { "model": "enterprise linux server aus", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "6.5" }, { "model": "enterprise linux server long life", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "5.9" }, { "model": "enterprise linux", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "5" }, { "model": "enterprise linux desktop", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "6.0" }, { "model": "enterprise linux server aus", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "7.6" }, { "model": "enterprise linux server aus", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "5.9" }, { "model": "enterprise linux server aus", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "7.2" }, { "model": "enterprise linux server tus", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "6.5" }, { "model": "enterprise linux server", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "7.0" }, { "model": "enterprise linux", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "7.0" }, { "model": "enterprise linux server tus", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "7.6" }, { "model": "enterprise linux server eus", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "6.5" }, { "model": "enterprise linux workstation", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "7.0" }, { "model": "enterprise linux server tus", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "7.2" }, { "model": "suse linux enterprise server", "scope": "eq", "trust": 1.0, "vendor": "novell", "version": "11.0" }, { "model": "web gateway", "scope": "lte", "trust": 1.0, "vendor": "mcafee", "version": "7.6.2.14" }, { "model": "linux enterprise server", "scope": "eq", "trust": 1.0, "vendor": "suse", "version": "12" }, { "model": "suse linux enterprise point of sale", "scope": "eq", "trust": 1.0, "vendor": "novell", "version": "11.0" }, { "model": "enterprise linux server eus", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "7.6" }, { "model": "leap", "scope": "eq", "trust": 1.0, "vendor": "opensuse", "version": "42.2" }, { "model": "enterprise linux server eus", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "7.2" }, { "model": "cloud magnum orchestration", "scope": "eq", "trust": 1.0, "vendor": "openstack", "version": "7" }, { "model": "enterprise linux server aus", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "6.2" }, { "model": "glibc", "scope": "lte", "trust": 1.0, "vendor": "gnu", "version": "2.25" }, { "model": "enterprise linux desktop", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "7.0" }, { "model": "linux enterprise software development kit", "scope": "eq", "trust": 1.0, "vendor": "suse", "version": "12.0" }, { "model": "enterprise linux server aus", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "7.4" }, { "model": "linux", "scope": "eq", "trust": 1.0, "vendor": "debian", "version": "9.0" }, { "model": "enterprise linux server aus", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "6.6" }, { "model": "enterprise linux server eus", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "6.2" }, { "model": "suse linux enterprise desktop", "scope": "eq", "trust": 1.0, "vendor": "novell", "version": "12.0" }, { "model": "enterprise linux server", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "6.6" }, { "model": "enterprise linux server aus", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "7.3" }, { "model": "web gateway", "scope": "lte", "trust": 1.0, "vendor": "mcafee", "version": "7.7.2.2" }, { "model": "web gateway", "scope": "gte", "trust": 1.0, "vendor": "mcafee", "version": "7.7.0.0" }, { "model": "linux enterprise server", "scope": "eq", "trust": 1.0, "vendor": "suse", "version": "10" }, { "model": "enterprise linux server eus", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "7.4" }, { "model": "enterprise linux server tus", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "7.3" }, { "model": "linux enterprise server", "scope": "eq", "trust": 1.0, "vendor": "suse", "version": "11" }, { "model": "enterprise linux server", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "6.0" }, { "model": "enterprise linux server eus", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "6.7" }, { "model": "enterprise linux server eus", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "7.5" }, { "model": "enterprise linux server aus", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "6.4" }, { "model": "enterprise linux server eus", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "7.3" }, { "model": "enterprise linux", "scope": "eq", "trust": 1.0, "vendor": "redhat", "version": "6.0" }, { "model": "linux enterprise server for raspberry pi", "scope": "eq", "trust": 1.0, "vendor": "suse", "version": "12" }, { "model": "c library", "scope": "lte", "trust": 0.8, "vendor": "gnu", "version": "2.25" }, { "model": "cloud magnum orchestration", "scope": null, "trust": 0.8, "vendor": "openstack", "version": null }, { "model": "leap", "scope": null, "trust": 0.8, "vendor": "opensuse", "version": null }, { "model": "linux enterprise desktop", "scope": null, "trust": 0.8, "vendor": "suse", "version": null }, { "model": "linux enterprise for sap", "scope": null, "trust": 0.8, "vendor": "suse", "version": null }, { "model": "linux enterprise point of sale", "scope": null, "trust": 0.8, "vendor": "suse", "version": null }, { "model": "linux enterprise server", "scope": null, "trust": 0.8, "vendor": "suse", "version": null }, { "model": "linux enterprise server for raspberry pi", "scope": null, "trust": 0.8, "vendor": "suse", "version": null }, { "model": "linux enterprise software development kit", "scope": null, "trust": 0.8, "vendor": "suse", "version": null }, { "model": "openstack cloud", "scope": null, "trust": 0.8, "vendor": "suse", "version": null }, { "model": "enterprise linux", "scope": null, "trust": 0.8, "vendor": "red hat", "version": null }, { "model": "enterprise linux aus", "scope": null, "trust": 0.8, "vendor": "red hat", "version": null }, { "model": "enterprise linux eus", "scope": null, "trust": 0.8, "vendor": "red hat", "version": null }, { "model": "enterprise linux long life", "scope": null, "trust": 0.8, "vendor": "red hat", "version": null }, { "model": "enterprise linux server", "scope": null, "trust": 0.8, "vendor": "red hat", "version": null }, { "model": "enterprise linux server eus", "scope": null, "trust": 0.8, "vendor": "red hat", "version": null }, { "model": "enterprise linux server tus", "scope": null, "trust": 0.8, "vendor": "red hat", "version": null } ], "sources": [ { "db": "JVNDB", "id": "JVNDB-2017-005209" }, { "db": "CNNVD", "id": "CNNVD-201706-808" }, { "db": "NVD", "id": "CVE-2017-1000366" } ] }, "configurations": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/configurations#", "children": { "@container": "@list" }, "cpe_match": { "@container": "@list" }, "data": { "@container": "@list" }, "nodes": { "@container": "@list" } }, "data": [ { "CVE_data_version": "4.0", "nodes": [ { "cpe_match": [ { "cpe22Uri": "cpe:/a:gnu:glibc", "vulnerable": true }, { "cpe22Uri": "cpe:/a:openstack:cloud_magnum_orchestration", "vulnerable": true }, { "cpe22Uri": "cpe:/o:opensuse_project:leap", "vulnerable": true }, { "cpe22Uri": "cpe:/o:suse:linux_enterprise_desktop", "vulnerable": true }, { "cpe22Uri": "cpe:/o:suse:linux_enterprise_for_sap", "vulnerable": true }, { "cpe22Uri": "cpe:/o:suse:suse_linux_enterprise_point_of_sale", "vulnerable": true }, { "cpe22Uri": "cpe:/o:suse:linux_enterprise_server", "vulnerable": true }, { "cpe22Uri": "cpe:/o:suse:linux_enterprise_server_for_raspberry_pi", "vulnerable": true }, { "cpe22Uri": "cpe:/o:suse:linux_enterprise_software_development_kit", "vulnerable": true }, { "cpe22Uri": "cpe:/a:suse:openstack_cloud", "vulnerable": true }, { "cpe22Uri": "cpe:/o:redhat:enterprise_linux", "vulnerable": true }, { "cpe22Uri": "cpe:/o:redhat:enterprise_linux_aus", "vulnerable": true }, { "cpe22Uri": "cpe:/o:redhat:enterprise_linux_eus", "vulnerable": true }, { "cpe22Uri": "cpe:/o:redhat:enterprise_linux_long_life", "vulnerable": true }, { "cpe22Uri": "cpe:/o:redhat:enterprise_linux_server", "vulnerable": true }, { "cpe22Uri": "cpe:/o:redhat:enterprise_linux_server_eus", "vulnerable": true }, { "cpe22Uri": "cpe:/o:redhat:enterprise_linux_server_tus", "vulnerable": true } ], "operator": "OR" } ] } ], "sources": [ { "db": "JVNDB", "id": "JVNDB-2017-005209" } ] }, "credits": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/credits#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "T. Weber", "sources": [ { "db": "PACKETSTORM", "id": "154361" }, { "db": "CNNVD", "id": "CNNVD-201706-808" } ], "trust": 0.7 }, "cve": "CVE-2017-1000366", "cvss": { "@context": { "cvssV2": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/cvss/cvssV2#" }, "@id": "https://www.variotdbs.pl/ref/cvss/cvssV2" }, "cvssV3": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/cvss/cvssV3#" }, "@id": "https://www.variotdbs.pl/ref/cvss/cvssV3/" }, "severity": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/cvss/severity#" }, "@id": "https://www.variotdbs.pl/ref/cvss/severity" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" }, "@id": "https://www.variotdbs.pl/ref/sources" } }, "data": [ { "cvssV2": [ { "accessComplexity": "LOW", "accessVector": "LOCAL", "authentication": "NONE", "author": "nvd@nist.gov", "availabilityImpact": "COMPLETE", "baseScore": 7.2, "confidentialityImpact": "COMPLETE", "exploitabilityScore": 3.9, "id": "CVE-2017-1000366", "impactScore": 10.0, "integrityImpact": "COMPLETE", "severity": "HIGH", "trust": 1.9, "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0" }, { "accessComplexity": "LOW", "accessVector": "LOCAL", "authentication": "NONE", "author": "VULHUB", "availabilityImpact": "COMPLETE", "baseScore": 7.2, "confidentialityImpact": "COMPLETE", "exploitabilityScore": 3.9, "id": "VHN-100094", "impactScore": 10.0, "integrityImpact": "COMPLETE", "severity": "HIGH", "trust": 0.1, "vectorString": "AV:L/AC:L/AU:N/C:C/I:C/A:C", "version": "2.0" } ], "cvssV3": [ { "attackComplexity": "LOW", "attackVector": "LOCAL", "author": "nvd@nist.gov", "availabilityImpact": "HIGH", "baseScore": 7.8, "baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "exploitabilityScore": 1.8, "id": "CVE-2017-1000366", "impactScore": 5.9, "integrityImpact": "HIGH", "privilegesRequired": "LOW", "scope": "UNCHANGED", "trust": 1.8, "userInteraction": "NONE", "vectorString": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.0" } ], "severity": [ { "author": "nvd@nist.gov", "id": "CVE-2017-1000366", "trust": 1.0, "value": "HIGH" }, { "author": "NVD", "id": "CVE-2017-1000366", "trust": 0.8, "value": "High" }, { "author": "CNNVD", "id": "CNNVD-201706-808", "trust": 0.6, "value": "HIGH" }, { "author": "VULHUB", "id": "VHN-100094", "trust": 0.1, "value": "HIGH" }, { "author": "VULMON", "id": "CVE-2017-1000366", "trust": 0.1, "value": "HIGH" } ] } ], "sources": [ { "db": "VULHUB", "id": "VHN-100094" }, { "db": "VULMON", "id": "CVE-2017-1000366" }, { "db": "JVNDB", "id": "JVNDB-2017-005209" }, { "db": "CNNVD", "id": "CNNVD-201706-808" }, { "db": "NVD", "id": "CVE-2017-1000366" } ] }, "description": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/description#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "glibc contains a vulnerability that allows specially crafted LD_LIBRARY_PATH values to manipulate the heap/stack, causing them to alias, potentially resulting in arbitrary code execution. Please note that additional hardening changes have been made to glibc to prevent manipulation of stack and heap memory but these issues are not directly exploitable, as such they have not been given a CVE. This affects glibc 2.25 and earlier. glibc Contains a buffer error vulnerability.Information is obtained, information is altered, and service operation is disrupted (DoS) There is a possibility of being put into a state. glibc (also known as GNU C Library, libc6) is an open source and free C language compiler released under the LGPL license agreement. \n-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\n=====================================================================\n Red Hat Security Advisory\n\nSynopsis: Important: glibc security update\nAdvisory ID: RHSA-2017:1479-01\nProduct: Red Hat Enterprise Linux\nAdvisory URL: https://access.redhat.com/errata/RHSA-2017:1479\nIssue date: 2017-06-19\nCVE Names: CVE-2017-1000366 \n=====================================================================\n\n1. Summary:\n\nAn update for glibc is now available for Red Hat Enterprise Linux 5\nExtended Lifecycle Support, Red Hat Enterprise Linux 5.9 Long Life, Red Hat\nEnterprise Linux 6.2 Advanced Update Support, Red Hat Enterprise Linux 6.4\nAdvanced Update Support, Red Hat Enterprise Linux 6.5 Advanced Update\nSupport, Red Hat Enterprise Linux 6.5 Telco Extended Update Support, Red\nHat Enterprise Linux 6.6 Advanced Update Support, Red Hat Enterprise Linux\n6.6 Telco Extended Update Support, Red Hat Enterprise Linux 6.7 Extended\nUpdate Support, and Red Hat Enterprise Linux 7.2 Extended Update Support. \n\nRed Hat Product Security has rated this update as having a security impact\nof Important. A Common Vulnerability Scoring System (CVSS) base score,\nwhich gives a detailed severity rating, is available for each vulnerability\nfrom the CVE link(s) in the References section. \n\n2. Relevant releases/architectures:\n\nRed Hat Enterprise Linux ComputeNode EUS (v. 7.2) - x86_64\nRed Hat Enterprise Linux ComputeNode Optional EUS (v. 7.2) - x86_64\nRed Hat Enterprise Linux HPC Node EUS (v. 6.7) - x86_64\nRed Hat Enterprise Linux HPC Node Optional EUS (v. 6.7) - x86_64\nRed Hat Enterprise Linux Long Life (v. 5.9 server) - i386, ia64, x86_64\nRed Hat Enterprise Linux Server (v. 5 ELS) - i386, s390x, x86_64\nRed Hat Enterprise Linux Server AUS (v. 6.2) - x86_64\nRed Hat Enterprise Linux Server AUS (v. 6.4) - x86_64\nRed Hat Enterprise Linux Server AUS (v. 6.5) - x86_64\nRed Hat Enterprise Linux Server AUS (v. 6.6) - x86_64\nRed Hat Enterprise Linux Server EUS (v. 6.7) - i386, ppc64, s390x, x86_64\nRed Hat Enterprise Linux Server EUS (v. 7.2) - ppc64, ppc64le, s390x, x86_64\nRed Hat Enterprise Linux Server Optional AUS (v. 6.2) - x86_64\nRed Hat Enterprise Linux Server Optional AUS (v. 6.4) - x86_64\nRed Hat Enterprise Linux Server Optional AUS (v. 6.5) - x86_64\nRed Hat Enterprise Linux Server Optional AUS (v. 6.6) - x86_64\nRed Hat Enterprise Linux Server Optional EUS (v. 6.7) - i386, ppc64, s390x, x86_64\nRed Hat Enterprise Linux Server Optional EUS (v. 7.2) - ppc64, ppc64le, s390x, x86_64\nRed Hat Enterprise Linux Server Optional TUS (v. 6.5) - x86_64\nRed Hat Enterprise Linux Server Optional TUS (v. 6.6) - x86_64\nRed Hat Enterprise Linux Server TUS (v. 6.5) - x86_64\nRed Hat Enterprise Linux Server TUS (v. 6.6) - x86_64\n\n3. Description:\n\nThe glibc packages provide the standard C libraries (libc), POSIX thread\nlibraries (libpthread), standard math libraries (libm), and the name\nservice cache daemon (nscd) used by multiple programs on the system. \nWithout these libraries, the Linux system cannot function correctly. This is glibc-side mitigation which blocks\nprocessing of LD_LIBRARY_PATH for programs running in secure-execution mode\nand reduces the number of allocations performed by the processing of\nLD_AUDIT, LD_PRELOAD, and LD_HWCAP_MASK, making successful exploitation of\nthis issue more difficult. (CVE-2017-1000366)\n\nRed Hat would like to thank Qualys Research Labs for reporting this issue. \n\n4. Solution:\n\nFor details on how to apply this update, which includes the changes\ndescribed in this advisory, refer to:\n\nhttps://access.redhat.com/articles/11258\n\nFor the update to take effect, all services linked to the glibc library\nmust be restarted, or the system rebooted. \n\n5. Bugs fixed (https://bugzilla.redhat.com/):\n\n1452543 - CVE-2017-1000366 glibc: heap/stack gap jumping via unbounded stack allocations\n\n6. Package List:\n\nRed Hat Enterprise Linux Long Life (v. 5.9 server):\n\nSource:\nglibc-2.5-107.el5_9.9.src.rpm\n\ni386:\nglibc-2.5-107.el5_9.9.i386.rpm\nglibc-2.5-107.el5_9.9.i686.rpm\nglibc-common-2.5-107.el5_9.9.i386.rpm\nglibc-debuginfo-2.5-107.el5_9.9.i386.rpm\nglibc-debuginfo-2.5-107.el5_9.9.i686.rpm\nglibc-debuginfo-common-2.5-107.el5_9.9.i386.rpm\nglibc-devel-2.5-107.el5_9.9.i386.rpm\nglibc-headers-2.5-107.el5_9.9.i386.rpm\nglibc-utils-2.5-107.el5_9.9.i386.rpm\nnscd-2.5-107.el5_9.9.i386.rpm\n\nia64:\nglibc-2.5-107.el5_9.9.i686.rpm\nglibc-2.5-107.el5_9.9.ia64.rpm\nglibc-common-2.5-107.el5_9.9.ia64.rpm\nglibc-debuginfo-2.5-107.el5_9.9.i686.rpm\nglibc-debuginfo-2.5-107.el5_9.9.ia64.rpm\nglibc-debuginfo-common-2.5-107.el5_9.9.i386.rpm\nglibc-devel-2.5-107.el5_9.9.ia64.rpm\nglibc-headers-2.5-107.el5_9.9.ia64.rpm\nglibc-utils-2.5-107.el5_9.9.ia64.rpm\nnscd-2.5-107.el5_9.9.ia64.rpm\n\nx86_64:\nglibc-2.5-107.el5_9.9.i686.rpm\nglibc-2.5-107.el5_9.9.x86_64.rpm\nglibc-common-2.5-107.el5_9.9.x86_64.rpm\nglibc-debuginfo-2.5-107.el5_9.9.i386.rpm\nglibc-debuginfo-2.5-107.el5_9.9.i686.rpm\nglibc-debuginfo-2.5-107.el5_9.9.x86_64.rpm\nglibc-debuginfo-common-2.5-107.el5_9.9.i386.rpm\nglibc-devel-2.5-107.el5_9.9.i386.rpm\nglibc-devel-2.5-107.el5_9.9.x86_64.rpm\nglibc-headers-2.5-107.el5_9.9.x86_64.rpm\nglibc-utils-2.5-107.el5_9.9.x86_64.rpm\nnscd-2.5-107.el5_9.9.x86_64.rpm\n\nRed Hat Enterprise Linux Server (v. 5 ELS):\n\nSource:\nglibc-2.5-123.el5_11.4.src.rpm\n\ni386:\nglibc-2.5-123.el5_11.4.i386.rpm\nglibc-2.5-123.el5_11.4.i686.rpm\nglibc-common-2.5-123.el5_11.4.i386.rpm\nglibc-debuginfo-2.5-123.el5_11.4.i386.rpm\nglibc-debuginfo-2.5-123.el5_11.4.i686.rpm\nglibc-debuginfo-common-2.5-123.el5_11.4.i386.rpm\nglibc-devel-2.5-123.el5_11.4.i386.rpm\nglibc-headers-2.5-123.el5_11.4.i386.rpm\nglibc-utils-2.5-123.el5_11.4.i386.rpm\nnscd-2.5-123.el5_11.4.i386.rpm\n\ns390x:\nglibc-2.5-123.el5_11.4.s390.rpm\nglibc-2.5-123.el5_11.4.s390x.rpm\nglibc-common-2.5-123.el5_11.4.s390x.rpm\nglibc-debuginfo-2.5-123.el5_11.4.s390.rpm\nglibc-debuginfo-2.5-123.el5_11.4.s390x.rpm\nglibc-devel-2.5-123.el5_11.4.s390.rpm\nglibc-devel-2.5-123.el5_11.4.s390x.rpm\nglibc-headers-2.5-123.el5_11.4.s390x.rpm\nglibc-utils-2.5-123.el5_11.4.s390x.rpm\nnscd-2.5-123.el5_11.4.s390x.rpm\n\nx86_64:\nglibc-2.5-123.el5_11.4.i686.rpm\nglibc-2.5-123.el5_11.4.x86_64.rpm\nglibc-common-2.5-123.el5_11.4.x86_64.rpm\nglibc-debuginfo-2.5-123.el5_11.4.i386.rpm\nglibc-debuginfo-2.5-123.el5_11.4.i686.rpm\nglibc-debuginfo-2.5-123.el5_11.4.x86_64.rpm\nglibc-debuginfo-common-2.5-123.el5_11.4.i386.rpm\nglibc-devel-2.5-123.el5_11.4.i386.rpm\nglibc-devel-2.5-123.el5_11.4.x86_64.rpm\nglibc-headers-2.5-123.el5_11.4.x86_64.rpm\nglibc-utils-2.5-123.el5_11.4.x86_64.rpm\nnscd-2.5-123.el5_11.4.x86_64.rpm\n\nRed Hat Enterprise Linux HPC Node EUS (v. 6.7):\n\nSource:\nglibc-2.12-1.166.el6_7.8.src.rpm\n\nx86_64:\nglibc-2.12-1.166.el6_7.8.i686.rpm\nglibc-2.12-1.166.el6_7.8.x86_64.rpm\nglibc-common-2.12-1.166.el6_7.8.x86_64.rpm\nglibc-debuginfo-2.12-1.166.el6_7.8.i686.rpm\nglibc-debuginfo-2.12-1.166.el6_7.8.x86_64.rpm\nglibc-debuginfo-common-2.12-1.166.el6_7.8.i686.rpm\nglibc-debuginfo-common-2.12-1.166.el6_7.8.x86_64.rpm\nglibc-devel-2.12-1.166.el6_7.8.i686.rpm\nglibc-devel-2.12-1.166.el6_7.8.x86_64.rpm\nglibc-headers-2.12-1.166.el6_7.8.x86_64.rpm\nglibc-utils-2.12-1.166.el6_7.8.x86_64.rpm\nnscd-2.12-1.166.el6_7.8.x86_64.rpm\n\nRed Hat Enterprise Linux HPC Node Optional EUS (v. 6.7):\n\nx86_64:\nglibc-debuginfo-2.12-1.166.el6_7.8.i686.rpm\nglibc-debuginfo-2.12-1.166.el6_7.8.x86_64.rpm\nglibc-debuginfo-common-2.12-1.166.el6_7.8.i686.rpm\nglibc-debuginfo-common-2.12-1.166.el6_7.8.x86_64.rpm\nglibc-static-2.12-1.166.el6_7.8.i686.rpm\nglibc-static-2.12-1.166.el6_7.8.x86_64.rpm\n\nRed Hat Enterprise Linux Server AUS (v. 6.2):\n\nSource:\nglibc-2.12-1.47.el6_2.18.src.rpm\n\nx86_64:\nglibc-2.12-1.47.el6_2.18.i686.rpm\nglibc-2.12-1.47.el6_2.18.x86_64.rpm\nglibc-common-2.12-1.47.el6_2.18.x86_64.rpm\nglibc-debuginfo-2.12-1.47.el6_2.18.i686.rpm\nglibc-debuginfo-2.12-1.47.el6_2.18.x86_64.rpm\nglibc-debuginfo-common-2.12-1.47.el6_2.18.i686.rpm\nglibc-debuginfo-common-2.12-1.47.el6_2.18.x86_64.rpm\nglibc-devel-2.12-1.47.el6_2.18.i686.rpm\nglibc-devel-2.12-1.47.el6_2.18.x86_64.rpm\nglibc-headers-2.12-1.47.el6_2.18.x86_64.rpm\nglibc-utils-2.12-1.47.el6_2.18.x86_64.rpm\nnscd-2.12-1.47.el6_2.18.x86_64.rpm\n\nRed Hat Enterprise Linux Server AUS (v. 6.4):\n\nSource:\nglibc-2.12-1.107.el6_4.10.src.rpm\n\nx86_64:\nglibc-2.12-1.107.el6_4.10.i686.rpm\nglibc-2.12-1.107.el6_4.10.x86_64.rpm\nglibc-common-2.12-1.107.el6_4.10.x86_64.rpm\nglibc-debuginfo-2.12-1.107.el6_4.10.i686.rpm\nglibc-debuginfo-2.12-1.107.el6_4.10.x86_64.rpm\nglibc-debuginfo-common-2.12-1.107.el6_4.10.i686.rpm\nglibc-debuginfo-common-2.12-1.107.el6_4.10.x86_64.rpm\nglibc-devel-2.12-1.107.el6_4.10.i686.rpm\nglibc-devel-2.12-1.107.el6_4.10.x86_64.rpm\nglibc-headers-2.12-1.107.el6_4.10.x86_64.rpm\nglibc-utils-2.12-1.107.el6_4.10.x86_64.rpm\nnscd-2.12-1.107.el6_4.10.x86_64.rpm\n\nRed Hat Enterprise Linux Server AUS (v. 6.5):\n\nSource:\nglibc-2.12-1.132.el6_5.9.src.rpm\n\nx86_64:\nglibc-2.12-1.132.el6_5.9.i686.rpm\nglibc-2.12-1.132.el6_5.9.x86_64.rpm\nglibc-common-2.12-1.132.el6_5.9.x86_64.rpm\nglibc-debuginfo-2.12-1.132.el6_5.9.i686.rpm\nglibc-debuginfo-2.12-1.132.el6_5.9.x86_64.rpm\nglibc-debuginfo-common-2.12-1.132.el6_5.9.i686.rpm\nglibc-debuginfo-common-2.12-1.132.el6_5.9.x86_64.rpm\nglibc-devel-2.12-1.132.el6_5.9.i686.rpm\nglibc-devel-2.12-1.132.el6_5.9.x86_64.rpm\nglibc-headers-2.12-1.132.el6_5.9.x86_64.rpm\nglibc-utils-2.12-1.132.el6_5.9.x86_64.rpm\nnscd-2.12-1.132.el6_5.9.x86_64.rpm\n\nRed Hat Enterprise Linux Server TUS (v. 6.5):\n\nSource:\nglibc-2.12-1.132.el6_5.9.src.rpm\n\nx86_64:\nglibc-2.12-1.132.el6_5.9.i686.rpm\nglibc-2.12-1.132.el6_5.9.x86_64.rpm\nglibc-common-2.12-1.132.el6_5.9.x86_64.rpm\nglibc-debuginfo-2.12-1.132.el6_5.9.i686.rpm\nglibc-debuginfo-2.12-1.132.el6_5.9.x86_64.rpm\nglibc-debuginfo-common-2.12-1.132.el6_5.9.i686.rpm\nglibc-debuginfo-common-2.12-1.132.el6_5.9.x86_64.rpm\nglibc-devel-2.12-1.132.el6_5.9.i686.rpm\nglibc-devel-2.12-1.132.el6_5.9.x86_64.rpm\nglibc-headers-2.12-1.132.el6_5.9.x86_64.rpm\nglibc-utils-2.12-1.132.el6_5.9.x86_64.rpm\nnscd-2.12-1.132.el6_5.9.x86_64.rpm\n\nRed Hat Enterprise Linux Server AUS (v. 6.6):\n\nSource:\nglibc-2.12-1.149.el6_6.12.src.rpm\n\nx86_64:\nglibc-2.12-1.149.el6_6.12.i686.rpm\nglibc-2.12-1.149.el6_6.12.x86_64.rpm\nglibc-common-2.12-1.149.el6_6.12.x86_64.rpm\nglibc-debuginfo-2.12-1.149.el6_6.12.i686.rpm\nglibc-debuginfo-2.12-1.149.el6_6.12.x86_64.rpm\nglibc-debuginfo-common-2.12-1.149.el6_6.12.i686.rpm\nglibc-debuginfo-common-2.12-1.149.el6_6.12.x86_64.rpm\nglibc-devel-2.12-1.149.el6_6.12.i686.rpm\nglibc-devel-2.12-1.149.el6_6.12.x86_64.rpm\nglibc-headers-2.12-1.149.el6_6.12.x86_64.rpm\nglibc-utils-2.12-1.149.el6_6.12.x86_64.rpm\nnscd-2.12-1.149.el6_6.12.x86_64.rpm\n\nRed Hat Enterprise Linux Server TUS (v. 6.6):\n\nSource:\nglibc-2.12-1.149.el6_6.12.src.rpm\n\nx86_64:\nglibc-2.12-1.149.el6_6.12.i686.rpm\nglibc-2.12-1.149.el6_6.12.x86_64.rpm\nglibc-common-2.12-1.149.el6_6.12.x86_64.rpm\nglibc-debuginfo-2.12-1.149.el6_6.12.i686.rpm\nglibc-debuginfo-2.12-1.149.el6_6.12.x86_64.rpm\nglibc-debuginfo-common-2.12-1.149.el6_6.12.i686.rpm\nglibc-debuginfo-common-2.12-1.149.el6_6.12.x86_64.rpm\nglibc-devel-2.12-1.149.el6_6.12.i686.rpm\nglibc-devel-2.12-1.149.el6_6.12.x86_64.rpm\nglibc-headers-2.12-1.149.el6_6.12.x86_64.rpm\nglibc-utils-2.12-1.149.el6_6.12.x86_64.rpm\nnscd-2.12-1.149.el6_6.12.x86_64.rpm\n\nRed Hat Enterprise Linux Server EUS (v. 6.7):\n\nSource:\nglibc-2.12-1.166.el6_7.8.src.rpm\n\ni386:\nglibc-2.12-1.166.el6_7.8.i686.rpm\nglibc-common-2.12-1.166.el6_7.8.i686.rpm\nglibc-debuginfo-2.12-1.166.el6_7.8.i686.rpm\nglibc-debuginfo-common-2.12-1.166.el6_7.8.i686.rpm\nglibc-devel-2.12-1.166.el6_7.8.i686.rpm\nglibc-headers-2.12-1.166.el6_7.8.i686.rpm\nglibc-utils-2.12-1.166.el6_7.8.i686.rpm\nnscd-2.12-1.166.el6_7.8.i686.rpm\n\nppc64:\nglibc-2.12-1.166.el6_7.8.ppc.rpm\nglibc-2.12-1.166.el6_7.8.ppc64.rpm\nglibc-common-2.12-1.166.el6_7.8.ppc64.rpm\nglibc-debuginfo-2.12-1.166.el6_7.8.ppc.rpm\nglibc-debuginfo-2.12-1.166.el6_7.8.ppc64.rpm\nglibc-debuginfo-common-2.12-1.166.el6_7.8.ppc.rpm\nglibc-debuginfo-common-2.12-1.166.el6_7.8.ppc64.rpm\nglibc-devel-2.12-1.166.el6_7.8.ppc.rpm\nglibc-devel-2.12-1.166.el6_7.8.ppc64.rpm\nglibc-headers-2.12-1.166.el6_7.8.ppc64.rpm\nglibc-utils-2.12-1.166.el6_7.8.ppc64.rpm\nnscd-2.12-1.166.el6_7.8.ppc64.rpm\n\ns390x:\nglibc-2.12-1.166.el6_7.8.s390.rpm\nglibc-2.12-1.166.el6_7.8.s390x.rpm\nglibc-common-2.12-1.166.el6_7.8.s390x.rpm\nglibc-debuginfo-2.12-1.166.el6_7.8.s390.rpm\nglibc-debuginfo-2.12-1.166.el6_7.8.s390x.rpm\nglibc-debuginfo-common-2.12-1.166.el6_7.8.s390.rpm\nglibc-debuginfo-common-2.12-1.166.el6_7.8.s390x.rpm\nglibc-devel-2.12-1.166.el6_7.8.s390.rpm\nglibc-devel-2.12-1.166.el6_7.8.s390x.rpm\nglibc-headers-2.12-1.166.el6_7.8.s390x.rpm\nglibc-utils-2.12-1.166.el6_7.8.s390x.rpm\nnscd-2.12-1.166.el6_7.8.s390x.rpm\n\nx86_64:\nglibc-2.12-1.166.el6_7.8.i686.rpm\nglibc-2.12-1.166.el6_7.8.x86_64.rpm\nglibc-common-2.12-1.166.el6_7.8.x86_64.rpm\nglibc-debuginfo-2.12-1.166.el6_7.8.i686.rpm\nglibc-debuginfo-2.12-1.166.el6_7.8.x86_64.rpm\nglibc-debuginfo-common-2.12-1.166.el6_7.8.i686.rpm\nglibc-debuginfo-common-2.12-1.166.el6_7.8.x86_64.rpm\nglibc-devel-2.12-1.166.el6_7.8.i686.rpm\nglibc-devel-2.12-1.166.el6_7.8.x86_64.rpm\nglibc-headers-2.12-1.166.el6_7.8.x86_64.rpm\nglibc-utils-2.12-1.166.el6_7.8.x86_64.rpm\nnscd-2.12-1.166.el6_7.8.x86_64.rpm\n\nRed Hat Enterprise Linux Server Optional AUS (v. 6.2):\n\nSource:\nglibc-2.12-1.47.el6_2.18.src.rpm\n\nx86_64:\nglibc-debuginfo-2.12-1.47.el6_2.18.i686.rpm\nglibc-debuginfo-2.12-1.47.el6_2.18.x86_64.rpm\nglibc-debuginfo-common-2.12-1.47.el6_2.18.i686.rpm\nglibc-debuginfo-common-2.12-1.47.el6_2.18.x86_64.rpm\nglibc-static-2.12-1.47.el6_2.18.i686.rpm\nglibc-static-2.12-1.47.el6_2.18.x86_64.rpm\n\nRed Hat Enterprise Linux Server Optional AUS (v. 6.4):\n\nSource:\nglibc-2.12-1.107.el6_4.10.src.rpm\n\nx86_64:\nglibc-debuginfo-2.12-1.107.el6_4.10.i686.rpm\nglibc-debuginfo-2.12-1.107.el6_4.10.x86_64.rpm\nglibc-debuginfo-common-2.12-1.107.el6_4.10.i686.rpm\nglibc-debuginfo-common-2.12-1.107.el6_4.10.x86_64.rpm\nglibc-static-2.12-1.107.el6_4.10.i686.rpm\nglibc-static-2.12-1.107.el6_4.10.x86_64.rpm\n\nRed Hat Enterprise Linux Server Optional AUS (v. 6.5):\n\nSource:\nglibc-2.12-1.132.el6_5.9.src.rpm\n\nx86_64:\nglibc-debuginfo-2.12-1.132.el6_5.9.i686.rpm\nglibc-debuginfo-2.12-1.132.el6_5.9.x86_64.rpm\nglibc-debuginfo-common-2.12-1.132.el6_5.9.i686.rpm\nglibc-debuginfo-common-2.12-1.132.el6_5.9.x86_64.rpm\nglibc-static-2.12-1.132.el6_5.9.i686.rpm\nglibc-static-2.12-1.132.el6_5.9.x86_64.rpm\n\nRed Hat Enterprise Linux Server Optional TUS (v. 6.5):\n\nSource:\nglibc-2.12-1.132.el6_5.9.src.rpm\n\nx86_64:\nglibc-debuginfo-2.12-1.132.el6_5.9.i686.rpm\nglibc-debuginfo-2.12-1.132.el6_5.9.x86_64.rpm\nglibc-debuginfo-common-2.12-1.132.el6_5.9.i686.rpm\nglibc-debuginfo-common-2.12-1.132.el6_5.9.x86_64.rpm\nglibc-static-2.12-1.132.el6_5.9.i686.rpm\nglibc-static-2.12-1.132.el6_5.9.x86_64.rpm\n\nRed Hat Enterprise Linux Server Optional AUS (v. 6.6):\n\nx86_64:\nglibc-debuginfo-2.12-1.149.el6_6.12.i686.rpm\nglibc-debuginfo-2.12-1.149.el6_6.12.x86_64.rpm\nglibc-debuginfo-common-2.12-1.149.el6_6.12.i686.rpm\nglibc-debuginfo-common-2.12-1.149.el6_6.12.x86_64.rpm\nglibc-static-2.12-1.149.el6_6.12.i686.rpm\nglibc-static-2.12-1.149.el6_6.12.x86_64.rpm\n\nRed Hat Enterprise Linux Server Optional TUS (v. 6.6):\n\nx86_64:\nglibc-debuginfo-2.12-1.149.el6_6.12.i686.rpm\nglibc-debuginfo-2.12-1.149.el6_6.12.x86_64.rpm\nglibc-debuginfo-common-2.12-1.149.el6_6.12.i686.rpm\nglibc-debuginfo-common-2.12-1.149.el6_6.12.x86_64.rpm\nglibc-static-2.12-1.149.el6_6.12.i686.rpm\nglibc-static-2.12-1.149.el6_6.12.x86_64.rpm\n\nRed Hat Enterprise Linux Server Optional EUS (v. 6.7):\n\ni386:\nglibc-debuginfo-2.12-1.166.el6_7.8.i686.rpm\nglibc-debuginfo-common-2.12-1.166.el6_7.8.i686.rpm\nglibc-static-2.12-1.166.el6_7.8.i686.rpm\n\nppc64:\nglibc-debuginfo-2.12-1.166.el6_7.8.ppc.rpm\nglibc-debuginfo-2.12-1.166.el6_7.8.ppc64.rpm\nglibc-debuginfo-common-2.12-1.166.el6_7.8.ppc.rpm\nglibc-debuginfo-common-2.12-1.166.el6_7.8.ppc64.rpm\nglibc-static-2.12-1.166.el6_7.8.ppc.rpm\nglibc-static-2.12-1.166.el6_7.8.ppc64.rpm\n\ns390x:\nglibc-debuginfo-2.12-1.166.el6_7.8.s390.rpm\nglibc-debuginfo-2.12-1.166.el6_7.8.s390x.rpm\nglibc-debuginfo-common-2.12-1.166.el6_7.8.s390.rpm\nglibc-debuginfo-common-2.12-1.166.el6_7.8.s390x.rpm\nglibc-static-2.12-1.166.el6_7.8.s390.rpm\nglibc-static-2.12-1.166.el6_7.8.s390x.rpm\n\nx86_64:\nglibc-debuginfo-2.12-1.166.el6_7.8.i686.rpm\nglibc-debuginfo-2.12-1.166.el6_7.8.x86_64.rpm\nglibc-debuginfo-common-2.12-1.166.el6_7.8.i686.rpm\nglibc-debuginfo-common-2.12-1.166.el6_7.8.x86_64.rpm\nglibc-static-2.12-1.166.el6_7.8.i686.rpm\nglibc-static-2.12-1.166.el6_7.8.x86_64.rpm\n\nRed Hat Enterprise Linux ComputeNode EUS (v. 7.2):\n\nSource:\nglibc-2.17-106.el7_2.9.src.rpm\n\nx86_64:\nglibc-2.17-106.el7_2.9.i686.rpm\nglibc-2.17-106.el7_2.9.x86_64.rpm\nglibc-common-2.17-106.el7_2.9.x86_64.rpm\nglibc-debuginfo-2.17-106.el7_2.9.i686.rpm\nglibc-debuginfo-2.17-106.el7_2.9.x86_64.rpm\nglibc-debuginfo-common-2.17-106.el7_2.9.i686.rpm\nglibc-debuginfo-common-2.17-106.el7_2.9.x86_64.rpm\nglibc-devel-2.17-106.el7_2.9.i686.rpm\nglibc-devel-2.17-106.el7_2.9.x86_64.rpm\nglibc-headers-2.17-106.el7_2.9.x86_64.rpm\nglibc-utils-2.17-106.el7_2.9.x86_64.rpm\nnscd-2.17-106.el7_2.9.x86_64.rpm\n\nRed Hat Enterprise Linux ComputeNode Optional EUS (v. 7.2):\n\nx86_64:\nglibc-debuginfo-2.17-106.el7_2.9.i686.rpm\nglibc-debuginfo-2.17-106.el7_2.9.x86_64.rpm\nglibc-debuginfo-common-2.17-106.el7_2.9.i686.rpm\nglibc-debuginfo-common-2.17-106.el7_2.9.x86_64.rpm\nglibc-static-2.17-106.el7_2.9.i686.rpm\nglibc-static-2.17-106.el7_2.9.x86_64.rpm\n\nRed Hat Enterprise Linux Server EUS (v. 7.2):\n\nSource:\nglibc-2.17-106.el7_2.9.src.rpm\n\nppc64:\nglibc-2.17-106.el7_2.9.ppc.rpm\nglibc-2.17-106.el7_2.9.ppc64.rpm\nglibc-common-2.17-106.el7_2.9.ppc64.rpm\nglibc-debuginfo-2.17-106.el7_2.9.ppc.rpm\nglibc-debuginfo-2.17-106.el7_2.9.ppc64.rpm\nglibc-debuginfo-common-2.17-106.el7_2.9.ppc.rpm\nglibc-debuginfo-common-2.17-106.el7_2.9.ppc64.rpm\nglibc-devel-2.17-106.el7_2.9.ppc.rpm\nglibc-devel-2.17-106.el7_2.9.ppc64.rpm\nglibc-headers-2.17-106.el7_2.9.ppc64.rpm\nglibc-utils-2.17-106.el7_2.9.ppc64.rpm\nnscd-2.17-106.el7_2.9.ppc64.rpm\n\nppc64le:\nglibc-2.17-106.el7_2.9.ppc64le.rpm\nglibc-common-2.17-106.el7_2.9.ppc64le.rpm\nglibc-debuginfo-2.17-106.el7_2.9.ppc64le.rpm\nglibc-debuginfo-common-2.17-106.el7_2.9.ppc64le.rpm\nglibc-devel-2.17-106.el7_2.9.ppc64le.rpm\nglibc-headers-2.17-106.el7_2.9.ppc64le.rpm\nglibc-utils-2.17-106.el7_2.9.ppc64le.rpm\nnscd-2.17-106.el7_2.9.ppc64le.rpm\n\ns390x:\nglibc-2.17-106.el7_2.9.s390.rpm\nglibc-2.17-106.el7_2.9.s390x.rpm\nglibc-common-2.17-106.el7_2.9.s390x.rpm\nglibc-debuginfo-2.17-106.el7_2.9.s390.rpm\nglibc-debuginfo-2.17-106.el7_2.9.s390x.rpm\nglibc-debuginfo-common-2.17-106.el7_2.9.s390.rpm\nglibc-debuginfo-common-2.17-106.el7_2.9.s390x.rpm\nglibc-devel-2.17-106.el7_2.9.s390.rpm\nglibc-devel-2.17-106.el7_2.9.s390x.rpm\nglibc-headers-2.17-106.el7_2.9.s390x.rpm\nglibc-utils-2.17-106.el7_2.9.s390x.rpm\nnscd-2.17-106.el7_2.9.s390x.rpm\n\nx86_64:\nglibc-2.17-106.el7_2.9.i686.rpm\nglibc-2.17-106.el7_2.9.x86_64.rpm\nglibc-common-2.17-106.el7_2.9.x86_64.rpm\nglibc-debuginfo-2.17-106.el7_2.9.i686.rpm\nglibc-debuginfo-2.17-106.el7_2.9.x86_64.rpm\nglibc-debuginfo-common-2.17-106.el7_2.9.i686.rpm\nglibc-debuginfo-common-2.17-106.el7_2.9.x86_64.rpm\nglibc-devel-2.17-106.el7_2.9.i686.rpm\nglibc-devel-2.17-106.el7_2.9.x86_64.rpm\nglibc-headers-2.17-106.el7_2.9.x86_64.rpm\nglibc-utils-2.17-106.el7_2.9.x86_64.rpm\nnscd-2.17-106.el7_2.9.x86_64.rpm\n\nRed Hat Enterprise Linux Server Optional EUS (v. 7.2):\n\nppc64:\nglibc-debuginfo-2.17-106.el7_2.9.ppc.rpm\nglibc-debuginfo-2.17-106.el7_2.9.ppc64.rpm\nglibc-debuginfo-common-2.17-106.el7_2.9.ppc.rpm\nglibc-debuginfo-common-2.17-106.el7_2.9.ppc64.rpm\nglibc-static-2.17-106.el7_2.9.ppc.rpm\nglibc-static-2.17-106.el7_2.9.ppc64.rpm\n\nppc64le:\nglibc-debuginfo-2.17-106.el7_2.9.ppc64le.rpm\nglibc-debuginfo-common-2.17-106.el7_2.9.ppc64le.rpm\nglibc-static-2.17-106.el7_2.9.ppc64le.rpm\n\ns390x:\nglibc-debuginfo-2.17-106.el7_2.9.s390.rpm\nglibc-debuginfo-2.17-106.el7_2.9.s390x.rpm\nglibc-debuginfo-common-2.17-106.el7_2.9.s390.rpm\nglibc-debuginfo-common-2.17-106.el7_2.9.s390x.rpm\nglibc-static-2.17-106.el7_2.9.s390.rpm\nglibc-static-2.17-106.el7_2.9.s390x.rpm\n\nx86_64:\nglibc-debuginfo-2.17-106.el7_2.9.i686.rpm\nglibc-debuginfo-2.17-106.el7_2.9.x86_64.rpm\nglibc-debuginfo-common-2.17-106.el7_2.9.i686.rpm\nglibc-debuginfo-common-2.17-106.el7_2.9.x86_64.rpm\nglibc-static-2.17-106.el7_2.9.i686.rpm\nglibc-static-2.17-106.el7_2.9.x86_64.rpm\n\nThese packages are GPG signed by Red Hat for security. Our key and\ndetails on how to verify the signature are available from\nhttps://access.redhat.com/security/team/key/\n\n7. References:\n\nhttps://access.redhat.com/security/cve/CVE-2017-1000366\nhttps://access.redhat.com/security/updates/classification/#important\nhttps://access.redhat.com/security/vulnerabilities/stackguard\n\n8. Contact:\n\nThe Red Hat security contact is \u003csecalert@redhat.com\u003e. More contact\ndetails at https://access.redhat.com/security/team/contact/\n\nCopyright 2017 Red Hat, Inc. \n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1\n\niD8DBQFZSDV3XlSAg2UNWIIRAibeAKC2QtxViqngTTBVM9fvG1XjRCkgwACgrHP1\nPVr1sUH9RUhxrQOKQqWtnKY=\n=ywUB\n-----END PGP SIGNATURE-----\n\n--\nRHSA-announce mailing list\nRHSA-announce@redhat.com\nhttps://www.redhat.com/mailman/listinfo/rhsa-announce\n. 6) - i386, x86_64\n\n3. For the full details, please refer to their advisory\npublished at:\nhttps://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt\n\nFor the oldstable distribution (jessie), this problem has been fixed\nin version 2.19-18+deb8u10. \n\nFor the stable distribution (stretch), this problem has been fixed in\nversion 2.24-11+deb9u1. \n\nFor the unstable distribution (sid), this problem will be fixed soon. \n\nWe recommend that you upgrade your glibc packages. \n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\nGentoo Linux Security Advisory GLSA 201706-19\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n https://security.gentoo.org/\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n\n Severity: High\n Title: GNU C Library: Multiple vulnerabilities\n Date: June 20, 2017\n Bugs: #608698, #608706, #622220\n ID: 201706-19\n\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n\nSynopsis\n========\n\nMultiple vulnerabilities have been found in the GNU C Library, the\nworst of which may allow execution of arbitrary code. \n\nBackground\n==========\n\nThe GNU C library is the standard C library used by Gentoo Linux\nsystems. \n\nImpact\n======\n\nAn attacker could possibly execute arbitrary code with the privileges\nof the process, escalate privileges or cause a Denial of Service\ncondition. \n\nWorkaround\n==========\n\nThere is no known workaround at this time. \n\nResolution\n==========\n\nAll GNU C Library users should upgrade to the latest version:\n\n # emerge --sync\n # emerge --ask --oneshot --verbose \"\u003e=sys-libs/glibc-2.23-r4\"\n\nReferences\n==========\n\n[ 1 ] CVE-2015-5180\n http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-5180\n[ 2 ] CVE-2016-6323\n http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-6323\n[ 3 ] CVE-2017-1000366\n http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-1000366\n[ 4 ] Qualys Security Advisory - The Stack Clash\n https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt\n\nAvailability\n============\n\nThis GLSA and any updates to it are available for viewing at\nthe Gentoo Security Website:\n\n https://security.gentoo.org/glsa/201706-19\n\nConcerns?\n=========\n\nSecurity is a primary focus of Gentoo Linux and ensuring the\nconfidentiality and security of our users\u0027 machines is of utmost\nimportance to us. Any security concerns should be addressed to\nsecurity@gentoo.org or alternatively, you may file a bug at\nhttps://bugs.gentoo.org. \n\nLicense\n=======\n\nCopyright 2017 Gentoo Foundation, Inc; referenced text\nbelongs to its owner(s). \n\nThe contents of this document are licensed under the\nCreative Commons - Attribution / Share Alike license. \n\nhttp://creativecommons.org/licenses/by-sa/2.5\n\n\n\n--cxbO5eT2swQBqr8k9tc6wcfapgLAJb4xR--\n\n. \nQualys Security Advisory\n\nThe Stack Clash\n\n\n========================================================================\nContents\n========================================================================\n\nI. Introduction\nII. Problem\n II.1. Automatic stack expansion\n II.2. Stack guard-page\n II.3. Stack-clash exploitation\nIII. Solutions\nIV. Results\n IV.1. Linux\n IV.2. OpenBSD\n IV.3. NetBSD\n IV.4. FreeBSD\n IV.5. Solaris\nV. Acknowledgments\n\n\n========================================================================\nI. Introduction\n========================================================================\n\nOur research started with a 96-megabyte surprise:\n\nb97bb000-b97dc000 rw-p 00000000 00:00 0 [heap]\nbf7c6000-bf806000 rw-p 00000000 00:00 0 [stack]\n\nand a 12-year-old question: \"If the heap grows up, and the stack grows\ndown, what happens when they clash? Is it exploitable? How?\"\n\n- In 2005, Gael Delalleau presented \"Large memory management\n vulnerabilities\" and the first stack-clash exploit in user-space\n (against mod_php 4.3.0 on Apache 2.0.53):\n\n http://cansecwest.com/core05/memory_vulns_delalleau.pdf\n\n- In 2010, Rafal Wojtczuk published \"Exploiting large memory management\n vulnerabilities in Xorg server running on Linux\", the second\n stack-clash exploit in user-space (CVE-2010-2240):\n\n http://www.invisiblethingslab.com/resources/misc-2010/xorg-large-memory-attacks.pdf\n\n- Since 2010, security researchers have exploited several stack-clashes\n in the kernel-space; for example:\n\n https://jon.oberheide.org/blog/2010/11/29/exploiting-stack-overflows-in-the-linux-kernel/\n https://jon.oberheide.org/files/infiltrate12-thestackisback.pdf\n https://googleprojectzero.blogspot.com/2016/06/exploiting-recursion-in-linux-kernel_20.html\n\nIn user-space, however, this problem has been greatly underestimated;\nthe only public exploits are Gael Delalleau\u0027s and Rafal Wojtczuk\u0027s, and\nthey were written before Linux introduced a protection against\nstack-clashes (a \"guard-page\" mapped below the stack):\n\nhttps://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-2240\n\nIn this advisory, we show that stack-clashes are widespread in\nuser-space, and exploitable despite the stack guard-page; we discovered\nmultiple vulnerabilities in guard-page implementations, and devised\ngeneral methods for:\n\n- \"Clashing\" the stack with another memory region: we allocate memory\n until the stack reaches another memory region, or until another memory\n region reaches the stack;\n\n- \"Jumping\" over the stack guard-page: we move the stack-pointer from\n the stack and into the other memory region, without accessing the\n stack guard-page;\n\n- \"Smashing\" the stack, or the other memory region: we overwrite the\n stack with the other memory region, or the other memory region with\n the stack. \n\nTo illustrate our findings, we developed the following exploits and\nproofs-of-concepts:\n\n- a local-root exploit against Exim (CVE-2017-1000369, CVE-2017-1000376)\n on i386 Debian;\n\n- a local-root exploit against Sudo (CVE-2017-1000367, CVE-2017-1000366)\n on i386 Debian, Ubuntu, CentOS;\n\n- an independent Sudoer-to-root exploit against CVE-2017-1000367 on any\n SELinux-enabled distribution;\n\n- a local-root exploit against ld.so and most SUID-root binaries\n (CVE-2017-1000366, CVE-2017-1000370) on i386 Debian, Fedora, CentOS;\n\n- a local-root exploit against ld.so and most SUID-root PIEs\n (CVE-2017-1000366, CVE-2017-1000371) on i386 Debian, Ubuntu, Fedora;\n\n- a local-root exploit against /bin/su (CVE-2017-1000366,\n CVE-2017-1000365) on i386 Debian;\n\n- a proof-of-concept that gains eip control against Sudo on i386\n grsecurity/PaX (CVE-2017-1000367, CVE-2017-1000366, CVE-2017-1000377);\n\n- a local proof-of-concept that gains rip control against Exim\n (CVE-2017-1000369) on amd64 Debian;\n\n- a local-root exploit against ld.so and most SUID-root binaries\n (CVE-2017-1000366, CVE-2017-1000379) on amd64 Debian, Ubuntu, Fedora,\n CentOS;\n\n- a proof-of-concept against /usr/bin/at on i386 OpenBSD, for\n CVE-2017-1000372 in OpenBSD\u0027s stack guard-page implementation and\n CVE-2017-1000373 in OpenBSD\u0027s qsort() function;\n\n- a proof-of-concept for CVE-2017-1000374 and CVE-2017-1000375 in\n NetBSD\u0027s stack guard-page implementation;\n\n- a proof-of-concept for CVE-2017-1085 in FreeBSD\u0027s setrlimit()\n RLIMIT_STACK implementation;\n\n- two proofs-of-concept for CVE-2017-1083 and CVE-2017-1084 in FreeBSD\u0027s\n stack guard-page implementation;\n\n- a local-root exploit against /usr/bin/rsh (CVE-2017-3630,\n CVE-2017-3629, CVE-2017-3631) on Solaris 11. \n\n\n========================================================================\nII. Problem\n========================================================================\n\nNote: in this advisory, the \"start of the stack\" is the lowest address\nof its memory region, and the \"end of the stack\" is the highest address\nof its memory region; we do not use the ambiguous terms \"top of the\nstack\" and \"bottom of the stack\". \n\n========================================================================\nII.1. Automatic stack expansion\n========================================================================\n\nThe user-space stack of a process is automatically expanded by the\nkernel:\n\n- if the stack-pointer (the esp register, on i386) reaches the start of\n the stack and the unmapped memory pages below (the stack grows down,\n on i386),\n\n- then a \"page-fault\" exception is raised and caught by the kernel,\n\n- and the page-fault handler transparently expands the user-space stack\n of the process (it decreases the start address of the stack),\n\n- or it terminates the process with a SIGSEGV if the stack expansion\n fails (for example, if the RLIMIT_STACK is reached). \n\nUnfortunately, this stack expansion mechanism is implicit and fragile:\nit relies on page-fault exceptions, but if another memory region is\nmapped directly below the stack, then the stack-pointer can move from\nthe stack into the other memory region without raising a page-fault,\nand:\n\n- the kernel cannot tell that the process needed more stack memory;\n\n- the process cannot tell that its stack-pointer moved from the stack\n into another memory region. \n\nIn contrast, the heap expansion mechanism is explicit and robust: the\nprocess uses the brk() system-call to tell the kernel that it needs more\nheap memory, and the kernel expands the heap accordingly (it increases\nthe end address of the heap memory region -- the heap always grows up). \n\n========================================================================\nII.2. Stack guard-page\n========================================================================\n\nThe fragile stack expansion mechanism poses a security threat: if the\nstack-pointer of a process can move from the stack into another memory\nregion (which ends exactly where the stack starts) without raising a\npage-fault, then:\n\n- the process uses this other memory region as if it were an extension\n of the stack;\n\n- a write to this stack extension smashes the other memory region;\n\n- a write to the other memory region smashes the stack extension. \n\nTo protect against this security threat, the kernel maps a \"guard-page\"\nbelow the start of the stack: one or more PROT_NONE pages (or unmappable\npages) that:\n\n- raise a page-fault exception if accessed (before the stack-pointer can\n move from the stack into another memory region);\n\n- terminate the process with a SIGSEGV (because the page-fault handler\n cannot expand the stack if another memory region is mapped directly\n below). \n\nUnfortunately, a stack guard-page of a few kilobytes is insufficient\n(CVE-2017-1000364): if the stack-pointer \"jumps\" over the guard-page --\nif it moves from the stack into another memory region without accessing\nthe guard-page -- then no page-fault exception is raised and the stack\nextends into the other memory region. \n\nThis theoretical vulnerability was first described in Gael Delalleau\u0027s\n2005 presentation (slides 24-29). In the present advisory, we discuss\nits practicalities, and multiple vulnerabilities in stack guard-page\nimplementations (in OpenBSD, NetBSD, and FreeBSD), but we exclude\nrelated vulnerabilities such as unbounded alloca()s and VLAs\n(Variable-Length Arrays) that have been exploited in the past:\n\nhttp://phrack.org/issues/63/14.html\nhttp://blog.exodusintel.com/2013/01/07/who-was-phone/\n\n========================================================================\nII.3. Stack-clash exploitation\n========================================================================\n\n Must be a clash, there\u0027s no alternative. \n --The Clash, \"Kingston Advice\"\n\nOur exploits follow a series of four sequential steps -- each step\nallocates memory that must not be freed before all steps are complete:\n\nStep 1: Clash (the stack with another memory region)\nStep 2: Run (move the stack-pointer to the start of the stack)\nStep 3: Jump (over the stack guard-page, into the other memory region)\nStep 4: Smash (the stack, or the other memory region)\n\n========================================================================\nII.3.1. Step 1: Clash the stack with another memory region\n========================================================================\n\n Have the boys found the leak yet?\n --The Clash, \"The Leader\"\n\nAllocate memory until the start of the stack reaches the end of another\nmemory region, or until the end of another memory region reaches the\nstart of the stack. \n\n- The other memory region can be, for example:\n . the heap;\n . an anonymous mmap();\n . the read-write segment of ld.so;\n . the read-write segment of a PIE, a Position-Independent Executable. \n\n- The memory allocated in this Step 1 can be, for example:\n . stack and heap memory;\n . stack and anonymous mmap() memory;\n . stack memory only. \n\n- The heap and anonymous mmap() memory can be:\n\n . temporarily allocated, but not freed before the stack guard-page is\n jumped over in Step 3 and memory is smashed in Step 4;\n\n . permanently leaked. On Linux, a general method for allocating\n anonymous mmap()s is the LD_AUDIT memory leak that we discovered in\n the ld.so part of the glibc, the GNU C Library (CVE-2017-1000366). \n\n- The stack memory can be allocated, for example:\n\n . through megabytes of command-line arguments and environment\n variables. \n\n On Linux, this general method for allocating stack memory is limited\n by the kernel to 1/4 of the current RLIMIT_STACK (1GB on i386 if\n RLIMIT_STACK is RLIM_INFINITY -- man execve, \"Limits on size of\n arguments and environment\"). \n\n However, as we were drafting this advisory, we realized that the\n kernel imposes this limit on the argument and environment strings,\n but not on the argv[] and envp[] pointers to these strings, and we\n developed alternative versions of our Linux exploits that do not\n depend on application-specific memory leaks (CVE-2017-1000365). through recursive function calls. \n\n On BSD, we discovered a general method for allocating megabytes of\n stack memory: a vulnerability in qsort() that causes this function\n to recurse N/4 times, given a pathological input array of N elements\n (CVE-2017-1000373 in OpenBSD, CVE-2017-1000378 in NetBSD, and\n CVE-2017-1082 in FreeBSD). \n\n- In a few rare cases, Step 1 is not needed, because another memory\n region is naturally mapped directly below the stack (for example,\n ld.so in our Solaris exploit). \n\n========================================================================\nII.3.2. Step 2: Move the stack-pointer to the start of the stack\n========================================================================\n\n Run, run, run, run, run, don\u0027t you know?\n --The Clash, \"Three Card Trick\"\n\nConsume the unused stack memory that separates the stack-pointer from\nthe start of the stack. This Step 2 is similar to Step 3 (\"Jump over the\nstack guard-page\") but is needed because:\n\n- the stack-pointer is usually several kilobytes higher than the start\n of the stack (functions that allocate a large stack-frame decrease the\n start address of the stack, but this address is never increased\n again); moreover:\n\n . the FreeBSD kernel automatically expands the user-space stack of a\n process by multiples of 128KB (SGROWSIZ, in vm_map_growstack());\n\n . the Linux kernel initially expands the user-space stack of a process\n by 128KB (stack_expand, in setup_arg_pages()). \n\n- in Step 3, the stack-based buffer used to jump over the guard-page:\n\n . is usually not large enough to simultaneously move the stack-pointer\n to the start of the stack, and then into another memory region;\n\n . must not be fully written to (a full write would access the stack\n guard-page and terminate the process) but the stack memory consumed\n in this Step 2 can be fully written to (for example, strdupa() can\n be used in Step 2, but not in Step 3). \n\nThe stack memory consumed in this Step 2 can be, for example:\n\n- large stack-frames, alloca()s, or VLAs (which can be detected by\n grsecurity/PaX\u0027s STACKLEAK plugin for GCC,\n https://grsecurity.net/features.php);\n\n- recursive function calls (which can be detected by GNU cflow,\n http://www.gnu.org/software/cflow/);\n\n- on Linux, we discovered that the argv[] and envp[] arrays of pointers\n can be used to consume the 128KB of initial stack expansion, because\n the kernel allocates these arrays on the stack long after the call to\n setup_arg_pages(); this general method for completing Step 2 is\n exploitable locally, but the initial stack expansion poses a major\n obstacle to the remote exploitation of stack-clashes, as mentioned in\n IV.1.1. \n\nIn a few rare cases, Step 2 is not needed, because the stack-pointer is\nnaturally close to the start of the stack (for example, in Exim\u0027s main()\nfunction, the 256KB group_list[] moves the stack-pointer to the start of\nthe stack and beyond). \n\n========================================================================\nII.3.3. Step 3: Jump over the stack guard-page, into another memory\nregion\n========================================================================\n\n You need a little jump of electrical shockers. \n --The Clash, \"Clash City Rockers\"\n\nMove the stack-pointer from the stack and into the memory region that\nclashed with the stack in Step 1, but without accessing the guard-page. \nTo complete this Step 3, a large stack-based buffer, alloca(), or VLA is\nneeded, and:\n\n- it must be larger than the guard-page;\n\n- it must end in the stack, above the guard-page;\n\n- it must start in the memory region below the stack guard-page;\n\n- it must not be fully written to (a full write would access the\n guard-page, raise a page-fault exception, and terminate the process,\n because the memory region mapped directly below the stack prevents the\n page-fault handler from expanding the stack). \n\nIn a few cases, Step 3 is not needed:\n\n- on FreeBSD, a stack guard-page is implemented but disabled by default\n (CVE-2017-1083);\n\n- on OpenBSD, NetBSD, and FreeBSD, we discovered implementation\n vulnerabilities that eliminate the stack guard-page (CVE-2017-1000372,\n CVE-2017-1000374, CVE-2017-1084). \n\nOn Linux, we devised general methods for jumping over the stack\nguard-page (CVE-2017-1000366):\n\n- The glibc\u0027s __dcigettext() function alloca()tes single_locale, a\n stack-based buffer of up to 128KB (MAX_ARG_STRLEN, man execve), the\n length of the LANGUAGE environment variable (if the current locale is\n neither \"C\" nor \"POSIX\", but distributions install default locales\n such as \"C.UTF-8\" and \"en_US.utf8\"). \n\n If LANGUAGE is mostly composed of \u0027:\u0027 characters, then single_locale\n is barely written to, and can be used to jump over the stack\n guard-page. \n\n Moreover, if __dcigettext() finds the message to be translated, then\n _nl_find_msg() strdup()licates the OUTPUT_CHARSET environment variable\n and allows a local attacker to immediately smash the stack and gain\n control of the instruction pointer (the eip register, on i386), as\n detailed in Step 4a. \n\n We exploited this stack-clash against Sudo and su, but most of the\n SUID (set-user-ID) and SGID (set-group-ID) binaries that call\n setlocale(LC_ALL, \"\") and __dcigettext() or its derivatives (the\n *gettext() functions, the _() convenience macro, the strerror()\n function) are exploitable. \n\n- The glibc\u0027s vfprintf() function (called by the *printf() family of\n functions) alloca()tes a stack-based work buffer of up to 64KB\n (__MAX_ALLOCA_CUTOFF) if a width or precision is greater than 1KB\n (WORK_BUFFER_SIZE). \n\n If the corresponding format specifier is %s then this work buffer is\n never written to and can be used to jump over the stack guard-page. \n\n None of our exploits is based on this method, but it was one of our\n ideas to exploit Exim remotely, as mentioned in IV.1.1. \n\n- The glibc\u0027s getaddrinfo() function calls gaih_inet(), which\n alloca()tes tmpbuf, a stack-based buffer of up to 64KB\n (__MAX_ALLOCA_CUTOFF) that may be used to jump over the stack\n guard-page. \n\n Moreover, gaih_inet() calls the gethostbyname*() functions, which\n malloc()ate a heap-based DNS response of up to 64KB (MAXPACKET) that\n may allow a remote attacker to immediately smash the stack, as\n detailed in Step 4a. \n\n None of our exploits is based on this method, but it may be the key to\n the remote exploitation of stack-clashes. \n\n- The glibc\u0027s run-time dynamic linker ld.so alloca()tes llp_tmp, a\n stack-based copy of the LD_LIBRARY_PATH environment variable. If\n LD_LIBRARY_PATH contains Dynamic String Tokens (DSTs), they are first\n expanded: llp_tmp can be larger than 128KB (MAX_ARG_STRLEN) and not\n fully written to, and can therefore be used to jump over the stack\n guard-page and smash the memory region mapped directly below, as\n detailed in Step 4b. \n\n We exploited this ld.so stack-clash in two data-only attacks that\n bypass NX (No-eXecute) and ASLR (Address Space Layout Randomization)\n and obtain a privileged shell through most SUID and SGID binaries on\n most i386 Linux distributions. \n\n- Several local and remote applications allocate a 256KB stack-based\n \"gid_t buffer[NGROUPS_MAX];\" that is not fully written to and can be\n used to move the stack-pointer to the start of the stack (Step 2) and\n jump over the guard-page (Step 3). For example, Exim\u0027s main() function\n and older versions of util-linux\u0027s su. \n\n None of our exploits is based on this method, but an experimental\n version of our Exim exploit unexpectedly gained control of eip after\n the group_list[] buffer had jumped over the stack guard-page. \n\n========================================================================\nII.3.4. Step 4: Either smash the stack with another memory region (Step\n4a) or smash another memory region with the stack (Step 4b)\n========================================================================\n\n Smash and grab, it\u0027s that kind of world. \n --The Clash, \"One Emotion\"\n\nIn Step 3, a function allocates a large stack-based buffer and jumps\nover the stack guard-page into the memory region mapped directly below;\nin Step 4, before this function returns and jumps back into the stack:\n\n- Step 4a: a write to the memory region mapped below the stack (where\n esp still points to) effectively smashes the stack. We exploit this\n general method for completing Step 4 in Exim, Sudo, and su:\n\n . we overwrite a return-address on the stack and gain control of eip;\n\n . we return-into-libc (into system() or __libc_dlopen()) to defeat NX;\n\n . we brute-force ASLR (8 bits of entropy) if CVE-2016-3672 is patched;\n\n . we bypass SSP (Stack-Smashing Protector) because we overwrite the\n return-address of a function that is not protected by a stack canary\n (the memcpy() that smashes the stack usually overwrites its own\n stack-frame and return-address). \n\n- Step 4b: a write to the stack effectively smashes the memory region\n mapped below (where esp still points to). This second method for\n completing Step 4 is application-specific (it depends on the contents\n of the memory region that we smash) unless we exploit the run-time\n dynamic linker ld.so:\n\n . on Solaris, we devised a general method for smashing ld.so\u0027s\n read-write segment, overwriting one of its function pointers, and\n executing our own shell-code;\n\n . on Linux, we exploited most SUID and SGID binaries through ld.so:\n our \"hwcap\" exploit smashes an mmap()ed string, and our \".dynamic\"\n exploit smashes a PIE\u0027s read-write segment before it is mprotect()ed\n read-only by Full RELRO (Full RELocate Read-Only -- GNU_RELRO and\n BIND_NOW). \n\n\n========================================================================\nIII. Solutions\n========================================================================\n\nBased on our research, we recommend that the affected operating systems:\n\n- Increase the size of the stack guard-page to at least 1MB, and allow\n system administrators to easily modify this value (for example,\n grsecurity/PaX introduced /proc/sys/vm/heap_stack_gap in 2010). \n\n This first, short-term solution is cheap, but it can be defeated by a\n very large stack-based buffer. \n\n- Recompile all userland code (ld.so, libraries, binaries) with GCC\u0027s\n \"-fstack-check\" option, which prevents the stack-pointer from moving\n into another memory region without accessing the stack guard-page (it\n writes one word to every 4KB page allocated on the stack). \n\n This second, long-term solution is expensive, but it cannot be\n defeated (even if the stack guard-page is only 4KB, one page) --\n unless a vulnerability is discovered in the implementation of the\n stack guard-page or the \"-fstack-check\" option. \n\n\n========================================================================\nIV. Results\n========================================================================\n\n========================================================================\nIV.1. Linux\n========================================================================\n\n========================================================================\nIV.1.1. Exim\n========================================================================\n\nDebian 8.5\n\nCrude exploitation\n\nOur first exploit, a Local Privilege Escalation against Exim\u0027s SUID-root\nPIE (Position-Independent Executable) on i386 Debian 8.5, simply follows\nthe four sequential steps outlined in II.3. \n\nStep 1: Clash the stack with the heap\n\nTo reach the start of the stack with the end of the heap (man brk), we\npermanently leak memory through multiple -p command-line arguments that\nare malloc()ated by Exim but never free()d (CVE-2017-1000369) -- we call\nsuch a malloc()ated chunk of heap memory a \"memleak-chunk\". \n\nBecause the -p argument strings are originally allocated on the stack by\nexecve(), we must cover half of the initial heap-stack distance (between\nthe start of the heap and the end of the stack) with stack memory, and\nhalf of this distance with heap memory. \n\nIf we set the RLIMIT_STACK to 136MB (MIN_GAP, arch/x86/mm/mmap.c) then\nthe initial heap-stack distance is minimal (randomized in a [96MB,137MB]\nrange), but we cannot reach the stack with the heap because of the 1/4\nlimit imposed by the kernel on the argument and environment strings (man\nexecve): 136MB/4=34MB of -p argument strings cannot cover 96MB/2=48MB,\nhalf of the minimum heap-stack distance. \n\nMoreover, if we increase the RLIMIT_STACK, the initial heap-stack\ndistance also increases and we still cannot reach the stack with the\nheap. However, if we set the RLIMIT_STACK to RLIM_INFINITY (4GB on i386)\nthen the kernel switches from the default top-down mmap() layout to a\nlegacy bottom-up mmap() layout, and:\n\n- the initial heap-stack distance is approximately 2GB, because the\n start of the heap (the initial brk()) is randomized above the address\n 0x40000000, and the end of the stack is randomized below the address\n 0xC0000000;\n\n- we can reach the stack with the heap, despite the 1/4 limit imposed by\n the kernel on the argument and environment strings, because 4GB/4=1GB\n of -p argument strings can cover 2GB/2=1GB, half of the initial\n heap-stack distance;\n\n- we clash the stack with the heap around the address 0x80000000. \n\nStep 2: Move the stack-pointer (esp) to the start of the stack\n\nThe 256KB stack-based group_list[] in Exim\u0027s main() naturally consumes\nthe 128KB of initial stack expansion, as mentioned in II.3.2. \n\nStep 3: Jump over the stack guard-page and into the heap\n\nTo move esp from the start of the stack into the heap, without accessing\nthe stack guard-page, we use a malformed -d command-line argument that\nis written to the 32KB (STRING_SPRINTF_BUFFER_SIZE) stack-based buffer\nin Exim\u0027s string_sprintf() function. This buffer is not fully written to\nand hence does not access the stack guard-page, because our -d argument\nstring is much shorter than 32KB. \n\nStep 4a: Smash the stack with the heap\n\nBefore string_sprintf() returns (and moves esp from the heap back into\nthe stack) it calls string_copy(), which malloc()ates and memcpy()es our\n-d argument string to the end of the heap, where esp still points to --\nwe call this malloc()ated chunk of heap memory the \"smashing-chunk\". \n\nThis call to memcpy() therefore smashes its own stack-frame (which is\nnot protected by SSP) with the contents of our smashing-chunk, and we\noverwrite memcpy()\u0027s return-address with the address of libc\u0027s system()\nfunction (which is not randomized by ASLR because Debian 8.5 is\nvulnerable to CVE-2016-3672):\n\n- instead of smashing memcpy()\u0027s stack-frame with an 8-byte pattern (the\n return-address to system() and its argument) we smash it with a simple\n 4-byte pattern (the return-address to system()), append \".\" to the\n PATH environment variable, and symlink() our exploit to the string\n that begins at the address of libc\u0027s system() function;\n\n- system() does not drop our escalated root privileges, because Debian\u0027s\n /bin/sh is dash, not bash and its -p option (man bash). \n\nThis first version of our Exim exploit obtained a root-shell after\nnearly a week of failed attempts; to improve this result, we analyzed\nevery step of a successful run. \n\nRefined exploitation\n\nStep 1: Clash the stack with the heap\n\n+ The heap must be able to reach the stack [Condition 1]\n\nThe start of the heap is randomized in the 32MB range above the end of\nExim\u0027s PIE (the end of its .bss section), but the growth of the heap is\nsometimes blocked by libraries that are mmap()ed within the same range\n(because of the legacy bottom-up mmap() layout). On Debian 8.5, Exim\u0027s\nlibraries occupy about 8MB and thus block the growth of the heap with a\nprobability of 8MB/32MB = 1/4. \n\nWhen the heap is blocked by the libraries, malloc() switches from brk()\nto mmap()s of 1MB (MMAP_AS_MORECORE_SIZE), and our memory leak reaches\nthe stack with mmap()s instead of the heap. Such a stack-clash is also\nexploitable, but its probability of success is low, as detailed in\nIV.1.6., and we therefore discarded this approach. \n\n+ The heap must always reach the stack, when not blocked by libraries\n\nBecause the initial heap-stack distance (between the start of the heap\nand the end of the stack) is a random variable:\n\n- either we allocate the exact amount of heap memory to cover the mean\n heap-stack distance, but the probability of success of this approach\n is low and we therefore discarded it;\n\n- or we allocate enough heap memory to always reach the stack, even when\n the initial heap-stack distance is maximal; after the heap reaches the\n stack, our memory leak allocates mmap()s of 1MB above the stack (below\n 0xC0000000) and below the heap (above the libraries), but it must not\n exhaust the address-space (the 1GB below 0x40000000 is unmappable);\n\n- the final heap-stack distance (between the end of the heap and the\n start of the stack) is also a random variable:\n\n . its minimum value is 8KB (the stack guard-page, plus a safety page\n imposed by the brk() system-call in mm/mmap.c);\n\n . its maximum value is roughly the size of a memleak-chunk, plus 128KB\n (DEFAULT_TOP_PAD, malloc/malloc.c). \n\nStep 3: Jump over the stack guard-page and into the heap\n\n- The stack-pointer must jump over the guard-page and land into the free\n chunk at the end of the heap (the remainder of the heap after malloc()\n switches from brk() to mmap()), where both the smashing-chunk and\n memcpy()\u0027s stack-frame are allocated and overwritten in Step 4a\n [Condition 2];\n\n- The write (of approximately smashing-chunk bytes) to\n string_sprintf()\u0027s stack-based buffer (which starts where the\n guard-page jump lands) must not crash into the end of the heap\n [Condition 3]. \n\nStep 4a: Smash the stack with the heap\n\nThe smashing-chunk must be allocated into the free chunk at the end of\nthe heap:\n\n- the smashing-chunk must not be allocated into the free chunks left\n over at the end of the 1MB mmap()s [Condition 4];\n\n- the memleak-chunks must not be allocated into the free chunk at the\n end of the heap [Condition 5]. \n\nIntuitively, the probability of gaining control of eip depends on the\nsize of the smashing-chunk (the guard-page jump\u0027s landing-zone) and the\nsize of the memleak-chunks (which determines the final heap-stack\ndistance). \n\nTo maximize this probability, we wrote a helper program that imposes the\nfollowing conditions on the smashing-chunk and memleak-chunks:\n\n- the smashing-chunk must be smaller than 32KB\n (STRING_SPRINTF_BUFFER_SIZE) [Condition 3];\n\n- the memleak-chunks must be smaller than 128KB (DEFAULT_MMAP_THRESHOLD,\n malloc/malloc.c);\n\n- the free chunk at the end of the heap must be larger than twice the\n smashing-chunk size [Conditions 2 and 3];\n\n- the free chunk at the end of the heap must be smaller than the\n memleak-chunk size [Condition 5];\n\n- when the final heap-stack distance is minimal, the 32KB\n (STRING_SPRINTF_BUFFER_SIZE) guard-page jump must land below the free\n chunk at the end of the heap [Condition 2];\n\n- the free chunks at the end of the 1MB mmap()s must be:\n\n . either smaller than the smashing-chunk [Condition 4];\n\n . or larger than the free chunk at the end of the heap (glibc\u0027s\n malloc() is a best-fit allocator) [Condition 4]. \n\nThe resulting smashing-chunk and memleak-chunk sizes are:\n\nsmash: 10224 memleak: 27656 brk_min: 20464 brk_max: 24552 mmap_top: 25304\nprobability: 1/16 (0.06190487817)\n\nIn theory, the probability of gaining control of eip is 1/21: the\nproduct of the 1/16 probability calculated by this helper program\n(approximately (smashing-chunk / (memleak-chunk + DEFAULT_TOP_PAD))) and\nthe 3/4 probability of reaching the stack with the heap [Condition 1]. \n\nIn practice, on Debian 8.5, our final Exim exploit:\n\n- gains eip control in 1 run out of 28, on average;\n\n- takes 2.5 seconds per run (on a 4GB Virtual Machine);\n\n- has a good chance of obtaining a root-shell after 28*2.5 = 70 seconds;\n\n- uses 4GB of memory (2GB in the Exim process, and 2GB in the process\n fork()ed by system()). \n\nDebian 8.6\n\nUnlike Debian 8.5, Debian 8.6 is not vulnerable to CVE-2016-3672: after\ngaining eip control in Step 4a (Smash), the probability of successfully\nreturning-into-libc\u0027s system() function is 1/256 (8 bits of entropy --\nlibraries are randomized in a 1MB range but aligned on 4KB). \n\nConsequently, our final Exim exploit has a good chance of obtaining a\nroot-shell on Debian 8.6 after 256*28*2.5 seconds = 5 hours (256*28=7168\nruns). \n\nAs we were drafting this advisory, we tried an alternative approach\nagainst Exim on Debian 8.6: we discovered that its stack is executable,\nbecause it depends on libgnutls-deb0, which depends on libp11-kit, which\ndepends on libffi, which incorrectly requires an executable GNU_STACK\n(CVE-2017-1000376). \n\nInitially, we discarded this approach because our 1GB of -p argument\nstrings on the stack is not executable (_dl_make_stack_executable() only\nmprotect()s the stack below argv[] and envp[]):\n\n41e00000-723d7000 rw-p 00000000 00:00 0 [heap]\n802f1000-80334000 rwxp 00000000 00:00 0 [stack]\n80334000-bfce6000 rw-p 00000000 00:00 0\n\nand because the stack is randomized in an 8MB range but we do not\ncontrol the contents of any large buffer on the executable stack. \n\nLater, we discovered that two 128KB (MAX_ARG_STRLEN) copies of the\nLD_PRELOAD environment variable can be allocated onto the executable\nstack by ld.so\u0027s dl_main() and open_path() functions, automatically\nfreed upon return from these functions, and re-allocated (but not\noverwritten) by Exim\u0027s 256KB stack-based group_list[]. \n\nIn theory, the probability of returning into our shell-code (into these\nexecutable copies of LD_PRELOAD) is 1/32 (2*128KB/8MB), higher than the\n1/256 probability of returning-into-libc. In practice, this alternative\nExim exploit has a good chance of obtaining a root-shell after 1174 runs\n-- instead of 32*28=896 runs in theory, because the two 128KB copies of\nLD_PRELOAD are never perfectly aligned with Exim\u0027s 256KB group_list[] --\nor 1174*2.5 seconds = 50 minutes. \n\nDebian 9 and 10\n\nUnlike Debian 8, Debian 9 and 10 are not vulnerable to offset2lib, a\nminor weakness in Linux\u0027s ASLR that coincidentally affects Step 1\n(Clash) of our stack-clash exploits:\n\nhttps://cybersecurity.upv.es/attacks/offset2lib/offset2lib.html\nhttps://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d1fd836dcf00d2028c700c7e44d2c23404062c90\n\nIf we set RLIMIT_STACK to RLIM_INFINITY, the kernel still switches to\nthe legacy bottom-up mmap() layout, and the libraries are randomized in\nthe 1MB range above the address 0x40000000, but Exim\u0027s PIE is randomized\nin the 1MB range above the address 0x80000000 and the heap is randomized\nin the 32MB range above the PIE\u0027s .bss section. As a result:\n\n- the heap is always able to reach the stack, because its growth is\n never blocked by the libraries -- the theoretical probability of\n gaining eip control is 1/16, the probability calculated by our helper\n program;\n\n- the heap clashes with the stack around the address 0xA0000000, because\n the initial heap-stack distance is 1GB (0xC0000000-0x80000000) and can\n be covered with 512MB of heap memory and 512MB of stack memory. \n\nRemote exploitation\n\nExim\u0027s string_sprintf() or glibc\u0027s vfprintf() can be used to remotely\ncomplete Steps 3 and 4 of the stack-clash; and the 256KB group_list[] in\nExim\u0027s main() naturally consumes the 128KB of initial stack expansion in\nStep 2; but another 256KB group_list[] in Exim\u0027s exim_setugid() further\ndecreases the start address of the stack and prevents us from remotely\ncompleting Step 2 and exploiting Exim. \n\n========================================================================\nIV.1.2. Sudo\n========================================================================\n\nIntroduction\n\nWe discovered a vulnerability in Sudo\u0027s get_process_ttyname() for Linux:\nthis function opens \"/proc/[pid]/stat\" (man proc) and reads the device\nnumber of the tty from field 7 (tty_nr). Unfortunately, these fields are\nspace-separated and field 2 (comm, the filename of the command) can\ncontain spaces (CVE-2017-1000367). \n\nFor example, if we execute Sudo through the symlink \"./ 1 \",\nget_process_ttyname() calls sudo_ttyname_dev() to search for the\nnon-existent tty device number \"1\" in the built-in search_devs[]. \n\nNext, sudo_ttyname_dev() calls the recursive function\nsudo_ttyname_scan() to search for this non-existent tty device number\n\"1\" in a breadth-first traversal of \"/dev\". \n\nLast, we exploit this recursive function during its traversal of the\nworld-writable \"/dev/shm\", and allocate hundreds of megabytes of heap\nmemory from the filesystem (directory pathnames) instead of the stack\n(the command-line arguments and environment variables allocated by our\nother stack-clash exploits). \n\nStep 1: Clash the stack with the heap\n\nsudo_ttyname_scan() strdup()licates the pathnames of the directories and\nsub-directories that it traverses, but does not free() them until it\nreturns. Each one of these \"memleak-chunks\" allocates at most 4KB\n(PATH_MAX) of heap memory. \n\nStep 2: Move the stack-pointer to the start of the stack\n\nThe recursive calls to sudo_ttyname_scan() allocate 4KB (PATH_MAX)\nstack-frames that naturally consume the 128KB of initial stack\nexpansion. \n\nStep 3: Jump over the stack guard-page and into the heap\n\nIf the length of a directory pathname reaches 4KB (PATH_MAX),\nsudo_ttyname_scan() calls warning(), which calls strerror() and _(),\nwhich call gettext() and allow us to jump over the stack guard-page with\nan alloca() of up to 128KB (the LANGUAGE environment variable), as\nexplained in II.3.3. \n\nStep 4a: Smash the stack with the heap\n\nThe self-contained gettext() exploitation method malloc()ates and\nmemcpy()es a \"smashing-chunk\" of up to 128KB (the OUTPUT_CHARSET\nenvironment variable) that smashes memcpy()\u0027s stack-frame and\nreturn-address, as explained in II.3.4. \n\nDebian 8.5\n\nStep 1: Clash the stack with the heap\n\nDebian 8.5 is vulnerable to CVE-2016-3672: if we set RLIMIT_STACK to\nRLIM_INFINITY, the kernel switches to the legacy bottom-up mmap() layout\nand disables the ASLR of Sudo\u0027s PIE and libraries, but still the initial\nheap-stack distance is randomized and roughly 2GB (0xC0000000-0x40000000\n-- the start of the heap is randomized in a 32MB range above 0x40000000,\nand the end of the stack is randomized in the 8MB range below\n0xC0000000). \n\nTo reach the start of the stack with the end of the heap, we allocate\nhundreds of megabytes of heap memory from the filesystem (directory\npathnames), and:\n\n- the heap must be able to reach the stack -- on Debian 8.5, Sudo\u0027s\n libraries occupy about 3MB and hence block the growth of the heap with\n a probability of 3MB/32MB ~= 1/11;\n\n- when not blocked by the libraries, the heap must always reach the\n stack, even when the initial heap-stack distance is maximal (as\n detailed in IV.1.1.);\n\n- we cover half of the initial heap-stack distance with 1GB of heap\n memory (the memleak-chunks, strdup()licated directory pathnames);\n\n- we cover the other half of this distance with 1GB of stack memory (the\n maximum permitted by the kernel\u0027s 1/4 limit on the argument and\n environment strings) and thus reduce our on-disk inode usage;\n\n- we redirect sudo_ttyname_scan()\u0027s traversal of /dev to /var/tmp\n (through a symlink planted in /dev/shm) to work around the small\n number of inodes available in /dev/shm. \n\nAfter the heap reaches the stack and malloc() switches from brk() to\nmmap()s of 1MB:\n\n- the size of the free chunk left over at the end of the heap is a\n random variable in the [0B,4KB] range -- 4KB (PATH_MAX) is the\n approximate size of a memleak-chunk;\n\n- the final heap-stack distance (between the end of the heap and the\n start of the stack) is a random variable in the [8KB,4KB+128KB=132KB]\n range -- the size of a memleak-chunk plus 128KB (DEFAULT_TOP_PAD);\n\n- sudo_ttyname_scan() recurses a few more times and therefore allocates\n more stack memory, but this stack expansion is blocked by the heap and\n crashes into the stack guard-page after 16 recursions on average\n (132KB/4KB/2, where 132KB is the maximum final heap-stack distance,\n and 4KB is the size of sudo_ttyname_scan()\u0027s stack-frame). \n\nTo solve this unexpected problem, we:\n\n- first, redirect sudo_ttyname_scan() to a directory tree \"A\" in\n /var/tmp that recurses and allocates stack memory, but does not\n allocate heap memory (each directory level contains only one entry,\n the sub-directory that is connected to the next directory level);\n\n- second, redirect sudo_ttyname_scan() to a directory tree \"B\" in\n /var/tmp that recurses and allocates heap memory (each directory level\n contains many entries), but does not allocate more stack memory (it\n simply consumes the stack memory that was already allocated by the\n directory tree \"A\"): it does not further expand the stack, and does\n not crash into the guard-page. \n\nFinally, we increase the speed of our exploit and avoid thousands of\nuseless recursions:\n\n- in each directory level traversed by sudo_ttyname_scan(), we randomly\n modify the names of its sub-directories until the first call to\n readdir() returns the only sub-directory that is connected to the next\n level of the directory tree (all other sub-directories allocate heap\n memory but are otherwise empty);\n\n- we dup2() Sudo\u0027s stdout and stderr to a pipe with no readers that\n terminates Sudo with a SIGPIPE if sudo_ttyname_scan() calls warning()\n and sudo_printf() (a failed exploit attempt, usually because the final\n heap-stack distance is much longer or shorter than the guard-page\n jump). \n\nStep 2: Move the stack-pointer to the start of the stack\n\nsudo_ttyname_scan() allocates a 4KB (PATH_MAX) stack-based pathbuf[]\nthat naturally consumes the 128KB of initial stack expansion in fewer\nthan 128KB/4KB=32 recursive calls. \n\nThe recursive calls to sudo_ttyname_scan() allocate less than 8MB of\nstack memory: the maximum number of recursions (PATH_MAX / strlen(\"/a\")\n= 2K) multiplied by the size of sudo_ttyname_scan()\u0027s stack-frame (4KB). \n\nStep 3: Jump over the stack guard-page and into the heap\n\nThe length of the guard-page jump in gettext() is the length of the\nLANGUAGE environment variable (at most 128KB, MAX_ARG_STRLEN): we take a\n64KB jump, well within the range of the final heap-stack distance; this\njump then lands into the free chunk at the end of the heap, where the\nsmashing-chunk will be allocated in Step 4a, with a probability of\n(smashing-chunk / (memleak-chunk + DEFAULT_TOP_PAD)). \n\nIf available, we assign \"C.UTF-8\" to the LC_ALL environment variable,\nand prepend \"be\" to our 64KB LANGUAGE environment variable, because\nthese minimal locales do not interfere with our heap feng-shui. \n\nStep 4a: Smash the stack with the heap\n\nIn gettext(), the smashing-chunk (a malloc() and memcpy() of the\nOUTPUT_CHARSET environment variable) must be allocated into the free\nchunk at the end of the heap, where the stack-frame of memcpy() is also\nallocated. \n\nFirst, if the size of our memleak-chunks is exactly 4KB+8B\n(PATH_MAX+MALLOC_ALIGNMENT), then:\n\n- the size of the free chunk at the end of the heap is a random variable\n in the [0B,4KB] range;\n\n- the size of the free chunks left over at the end of the 1MB mmap()s is\n roughly 1MB%(4KB+8B)=2KB. \n\nSecond, if the size of our smashing-chunk is about 2KB+256B\n(PATH_MAX/2+NAME_MAX), then:\n\n- it is always larger than (and never allocated into) the free chunks at\n the end of the 1MB mmap()s;\n\n- it is smaller than (and allocated into) the free chunk at the end of\n the heap with a probability of roughly 1-(2KB+256B)/4KB. \n\nLast, in each level of our directory tree \"B\", sudo_ttyname_scan()\nmalloc()ates and realloc()ates an array of pointers to sub-directories,\nbut these realloc()s prevent the smashing-chunk from being allocated\ninto the free chunk at the end of the heap:\n\n- they create holes in the heap, where the smashing-chunk may be\n allocated to;\n\n- they may allocate the free chunk at the end of the heap, where the\n smashing-chunk should be allocated to. \n\nTo solve these problems, we carefully calculate the number of\nsub-directories in each level of our directory tree \"B\":\n\n- we limit the size of the realloc()s -- and hence the size of the holes\n that they create -- to 4KB+2KB:\n\n . either a memleak-chunk is allocated into such a hole, and the\n remainder is smaller than the smashing-chunk (\"not a fit\");\n\n . or such a hole is not allocated, but it is larger than the largest\n free chunk at the end of the heap (\"a worse fit\");\n\n- we gradually reduce the final size of the realloc()s in the last\n levels of our directory tree \"B\", and hence re-allocate the holes\n created in the previous levels. \n\nIn theory, on Debian 8.5, the probability of gaining control of eip is\napproximately 1/148, the product of:\n\n- (Step 1) the probability of reaching the stack with the heap:\n 1-3MB/32MB;\n\n- (Step 3) the probability of jumping over the stack guard-page and into\n the free chunk at the end of the heap: (2KB+256B) / (4KB+8B + 128KB);\n\n- (Step 4a) the probability of allocating the smashing-chunk into the\n free chunk at the end of the heap: 1-(2KB+256B)/4KB. \n\nIn practice, on Debian 8.5, this Sudo exploit:\n\n- gains eip control in 1 run out of 200, on average;\n\n- takes 2.8 seconds per run (on a 4GB Virtual Machine);\n\n- has a good chance of obtaining a root-shell after 200 * 2.8 seconds =\n 9 minutes;\n\n- uses 2GB of memory. \n\nNote: we do not return-into-libc\u0027s system() in Step 4a because /bin/sh\nmay be bash, which drops our escalated root privileges upon execution. \nInstead, we:\n\n- either return-into-libc\u0027s __gconv_find_shlib() function through\n find_module(), which loads this function\u0027s argument from -0x20(%ebp);\n\n- or return-into-libc\u0027s __libc_dlopen_mode() function through\n nss_load_library(), which loads this function\u0027s argument from\n -0x1c(%ebp);\n\n- search the libc for a relative pathname that contains a slash\n character (for example, \"./fork.c\") and pass its address to\n __gconv_find_shlib() or __libc_dlopen_mode();\n\n- symlink() our PIE exploit to this pathname, and let Sudo execute our\n _init() constructor as root, upon successful exploitation. \n\nDebian 8.6\n\nUnlike Debian 8.5, Debian 8.6 is not vulnerable to CVE-2016-3672: Sudo\u0027s\nPIE and libraries are always randomized, even if we set RLIMIT_STACK to\nRLIM_INFINITY; the probability of successfully returning-into-libc,\nafter gaining eip control in Step 4a (Smash), is 1/256. \n\nHowever, Debian 8.6 is still vulnerable to offset2lib, the minor\nweakness in Linux\u0027s ASLR that coincidentally affects Step 1 (Clash) of\nour stack-clash exploits:\n\n- if we set RLIMIT_STACK to 136MB (MIN_GAP) or less (the default is\n 8MB), then the initial heap-stack distance (between the start of the\n heap and the end of the stack) is minimal, a random variable in the\n [96MB,137MB] range;\n\n- instead of allocating 1GB of heap memory and 1GB of stack memory to\n clash the stack with the heap, we merely allocate 137MB of heap memory\n (directory pathnames from our directory tree \"B\") and no stack memory. \n\nIn theory, on Debian 8.6, the probability of gaining eip control is\n1/134 (instead of 1/148 on Debian 8.5) because the growth of the heap is\nnever blocked by Sudo\u0027s libraries; and in practice, this Sudo exploit\ntakes only 0.15 second per run (instead of 2.8 on Debian 8.5). \n\nIndependent exploitation\n\nThe vulnerability that we discovered in Sudo\u0027s get_process_ttyname()\nfunction for Linux (CVE-2017-1000367) is exploitable independently of\nits stack-clash repercussions: through this vulnerability, a local user\ncan pretend that his tty is any character device on the filesystem, and\nafter two race conditions, he can pretend that his tty is any file on\nthe filesystem. \n\nOn an SELinux-enabled system, if a user is Sudoer for a command that\ndoes not grant him full root privileges, he can overwrite any file on\nthe filesystem (including root-owned files) with this command\u0027s output,\nbecause relabel_tty() (in src/selinux.c) calls open(O_RDWR|O_NONBLOCK)\non his tty and dup2()s it to the command\u0027s stdin, stdout, and stderr. \n\nTo exploit this vulnerability, we:\n\n- create a directory \"/dev/shm/_tmp\" (to work around\n /proc/sys/fs/protected_symlinks), and a symlink \"/dev/shm/_tmp/_tty\"\n to a non-existent pty \"/dev/pts/57\", whose device number is 34873;\n\n- run Sudo through a symlink \"/dev/shm/_tmp/ 34873 \" that spoofs the\n device number of this non-existent pty;\n\n- set the flag CD_RBAC_ENABLED through the command-line option \"-r role\"\n (where \"role\" can be our current role, for example \"unconfined_r\");\n\n- monitor our directory \"/dev/shm/_tmp\" (for an IN_OPEN inotify event)\n and wait until Sudo opendir()s it (because sudo_ttyname_dev() cannot\n find our non-existent pty in \"/dev/pts/\");\n\n- SIGSTOP Sudo, call openpty() until it creates our non-existent pty,\n and SIGCONT Sudo;\n\n- monitor our directory \"/dev/shm/_tmp\" (for an IN_CLOSE_NOWRITE inotify\n event) and wait until Sudo closedir()s it;\n\n- SIGSTOP Sudo, replace the symlink \"/dev/shm/_tmp/_tty\" to our\n now-existent pty with a symlink to the file that we want to overwrite\n (for example \"/etc/passwd\"), and SIGCONT Sudo;\n\n- control the output of the command executed by Sudo (the output that\n overwrites \"/etc/passwd\"):\n\n . either through a command-specific method;\n\n . or through a general method such as \"--\\nHELLO\\nWORLD\\n\" (by\n default, getopt() prints an error message to stderr if it does not\n recognize an option character). \n\nTo reliably win the two SIGSTOP races, we preempt the Sudo process: we\nsetpriority() it to the lowest priority, sched_setscheduler() it to\nSCHED_IDLE, and sched_setaffinity() it to the same CPU as our exploit. \n\n[john@localhost ~]$ head -n 8 /etc/passwd\nroot:x:0:0:root:/root:/bin/bash\nbin:x:1:1:bin:/bin:/sbin/nologin\ndaemon:x:2:2:daemon:/sbin:/sbin/nologin\nadm:x:3:4:adm:/var/adm:/sbin/nologin\nlp:x:4:7:lp:/var/spool/lpd:/sbin/nologin\nsync:x:5:0:sync:/sbin:/bin/sync\nshutdown:x:6:0:shutdown:/sbin:/sbin/shutdown\nhalt:x:7:0:halt:/sbin:/sbin/halt\n\n[john@localhost ~]$ sudo -l\n[sudo] password for john:\n... \nUser john may run the following commands on localhost:\n (ALL) /usr/bin/sum\n\n[john@localhost ~]$ ./Linux_sudo_CVE-2017-1000367 /usr/bin/sum $\u0027--\\nHELLO\\nWORLD\\n\u0027\n[sudo] password for john:\n\n[john@localhost ~]$ head -n 8 /etc/passwd\n/usr/bin/sum: unrecognized option \u0027--\nHELLO\nWORLD\n\u0027\nTry \u0027/usr/bin/sum --help\u0027 for more information. \nogin\nadm:x:3:4:adm:/var/adm:/sbin/nologin\nlp:x:4:7:lp:/var/spool/lpd:/sbin/nologin\n\n========================================================================\nIV.1.3. ld.so \"hwcap\" exploit\n========================================================================\n\n\"ld.so and ld-linux.so* find and load the shared libraries needed by a\nprogram, prepare the program to run, and then run it.\" (man ld.so)\n\nThrough ld.so, most SUID and SGID binaries on most i386 Linux\ndistributions are exploitable. For example: Debian 7, 8, 9, 10; Fedora\n23, 24, 25; CentOS 5, 6, 7. \n\nDebian 8.5\n\nStep 1: Clash the stack with anonymous mmap()s\n\nThe minimal malloc() implementation in ld.so calls mmap(), not brk(), to\nobtain memory from the system, and it never calls munmap(). To reach the\nstart of the stack with anonymous mmap()s, we:\n\n- set RLIMIT_STACK to RLIM_INFINITY and switch from the default top-down\n mmap() layout to the legacy bottom-up mmap() layout;\n\n- cover half of the initial mmap-stack distance\n (0xC0000000-0x40000000=2GB) with 1GB of stack memory (the maximum\n permitted by the kernel\u0027s 1/4 limit on the argument and environment\n strings);\n\n- cover the other half of this distance with 1GB of anonymous mmap()s,\n through multiple LD_AUDIT environment variables that permanently leak\n millions of audit_list structures (CVE-2017-1000366) in\n process_envvars() and process_dl_audit() (elf/rtld.c). \n\nStep 2: Move the stack-pointer to the start of the stack\n\nTo consume the 128KB of initial stack expansion, we simply pass 128KB of\nargv[] and envp[] pointers to execve(), as explained in II.3.2. \n\nStep 3: Jump over the stack guard-page and into the anonymous mmap()s\n\n_dl_init_paths() (elf/dl-load.c), which is called by dl_main() after\nprocess_envvars(), alloca()tes llp_tmp, a stack-based buffer large\nenough to hold the LD_LIBRARY_PATH environment variable and any\ncombination of Dynamic String Token (DST) replacement strings. To\ncalculate the size of llp_tmp, _dl_init_paths() must:\n\n- first, scan LD_LIBRARY_PATH and count all DSTs ($LIB, $PLATFORM, and\n $ORIGIN);\n\n- second, multiply the number of DSTs by the length of the longest DST\n replacement string (on Debian, $LIB is replaced by the 18-char-long\n \"lib/i386-linux-gnu\", $PLATFORM by \"i386\" or \"i686\", and $ORIGIN by\n the pathname of the program\u0027s directory, for example \"/bin\" or\n \"/usr/sbin\" -- the longest DST replacement string is usually\n \"lib/i386-linux-gnu\");\n\n- last, add the length of the original LD_LIBRARY_PATH. \n\nConsequently, if LD_LIBRARY_PATH contains many DSTs that are replaced by\nthe shortest DST replacement string, then llp_tmp is large but not fully\nwritten to, and can be used to jump over the stack guard-page and into\nthe anonymous mmap()s. \n\nOur ld.so exploits do not use $ORIGIN because it is ignored by several\ndistributions and glibc versions; for example:\n\n2010-12-09 Andreas Schwab \u003cschwab@redhat.com\u003e\n\n * elf/dl-object.c (_dl_new_object): Ignore origin of privileged\n program. \n\nIndex: glibc-2.12-2-gc4ccff1/elf/dl-object.c\n===================================================================\n--- glibc-2.12-2-gc4ccff1.orig/elf/dl-object.c\n+++ glibc-2.12-2-gc4ccff1/elf/dl-object.c\n@@ -214,6 +214,9 @@ _dl_new_object (char *realname, const ch\n out:\n new-\u003el_origin = origin;\n }\n+ else if (INTUSE(__libc_enable_secure) \u0026\u0026 type == lt_executable)\n+ /* The origin of a privileged program cannot be trusted. */\n+ new-\u003el_origin = (char *) -1;\n\n return new;\n }\n\nStep 4b: Smash an anonymous mmap() with the stack\n\nBefore _dl_init_paths() returns to dl_main() and jumps back from the\nanonymous mmap()s into the stack, we overwrite the block of mmap()ed\nmemory malloc()ated by _dl_important_hwcaps() with the contents of the\nstack-based buffer llp_tmp. \n\n- The block of memory malloc()ated by _dl_important_hwcaps() is divided\n in two:\n\n . The first part (the \"hwcap-pointers\") is an array of r_strlenpair\n structures that point to the hardware-capability strings stored in\n the second part of this memory block. The second part (the \"hwcap-strings\") contains strings of\n hardware-capabilities that are appended to the pathnames of trusted\n directories, such as \"/lib/\" and \"/lib/i386-linux-gnu/\", when\n open_path() searches for audit libraries (LD_AUDIT), preload\n libraries (LD_PRELOAD), or dependent libraries (DT_NEEDED). \n\n For example, on Debian, when open_path() finds \"libc.so.6\" in\n \"/lib/i386-linux-gnu/i686/cmov/\", \"i686/cmov/\" is such a\n hardware-capability string. \n\n- To overwrite the block of memory malloc()ated by\n _dl_important_hwcaps() with the contents of the stack-based buffer\n llp_tmp, we divide our LD_LIBRARY_PATH environment variable in two:\n\n . The first, static part (our \"good-write\") overwrites the first\n hardware-capability string with characters that we do control. The second, dynamic part (our \"bad-write\") overwrites the last\n hardware-capability strings with characters that we do not control\n (the short DST replacement strings that enlarge llp_tmp and allow us\n to jump over the stack guard-page). \n\nIf our 16-byte-aligned good-write overwrites the 8-byte-aligned first\nhardware-capability string with the 8-byte pattern \"/../tmp/\", and if we\nappend the trusted directory \"/lib\" to our LD_LIBRARY_PATH, then (after\n_dl_init_paths() returns to dl_main()):\n\n- dlmopen_doit() tries to load an LD_AUDIT library \"a\" (our memory leak\n from Step 1);\n\n- _dl_map_object() searches for \"a\" in the trusted directory \"/lib\" from\n our LD_LIBRARY_PATH;\n\n- open_path() finds our library \"a\" in \"/lib//../tmp//../tmp//../tmp/\"\n because we overwrote the first hardware-capability string with the\n pattern \"/../tmp/\";\n\n- dl_open_worker() executes our library\u0027s _init() constructor, as root. \n\nIn theory, this exploit\u0027s probability of success depends on:\n\n- (event A) the size of rtld_search_dirs.dirs[0], an array of\n r_search_path_elem structures that are malloc()ated by\n _dl_init_paths() after the _dl_important_hwcaps(), and must be\n allocated above the stack (below 0xC0000000), not below the stack\n where it would interfere with Steps 3 (Jump) and 4b (Smash):\n\nP(A) = 1 - size of rtld_search_dirs.dirs[0] / max stack randomization\n\n- (event B) the size of the hwcap-pointers and the size of our\n good-write, which must overwrite the first hardware-capability string,\n but not the first hardware-capability pointer (to this string):\n\nP(B|A) = MIN(size of hwcap-pointers, size of good-write) /\n (max stack randomization - size of rtld_search_dirs.dirs[0])\n\n- (event C) the size of the hwcap-strings and the size of our bad-write,\n which must not write past the end of hwcap-strings; but we guarantee\n that size of hwcap-strings \u003e= size of good-write + size of bad-write:\n\nP(C|B) = 1\n\nIn practice, we use the LD_HWCAP_MASK environment variable to maximize\nthis exploit\u0027s probability of success, because:\n\n- the size of the hwcap-pointers -- which act as a cushion that absorbs\n the excess of good-write without crashing,\n\n- the size of the hwcap-strings -- which act as a cushion that absorbs\n the excess of good-write and bad-write without crashing,\n\n- and the size of rtld_search_dirs.dirs[0],\n\nare all proportional to 2^N, where N is the number of supported\nhardware-capabilities that we enable in LD_HWCAP_MASK. \n\nFor example, on Debian 8.5, this exploit:\n\n- has a 1/151 probability of success;\n\n- takes 5.5 seconds per run (on a 4GB Virtual Machine);\n\n- has a good chance of obtaining a root-shell after 151 * 5.5 seconds =\n 14 minutes. \n\nDebian 8.6\n\nUnlike Debian 8.5, Debian 8.6 is not vulnerable to CVE-2016-3672, but\nour ld.so \"hwcap\" exploit is a data-only attack and is not affected by\nthe ASLR of the libraries and PIEs. \n\nDebian 9 and 10\n\nUnlike Debian 8, Debian 9 and 10 are not vulnerable to offset2lib: if we\nset RLIMIT_STACK to RLIM_INFINITY, the libraries are randomized above\nthe address 0x40000000, but the PIE is randomized above 0x80000000\n(instead of 0x40000000 before the offset2lib patch). \n\nUnfortunately, we discovered a vulnerability in the offset2lib patch\n(CVE-2017-1000370): if the PIE is execve()d with 1GB of argument or\nenvironment strings (the maximum permitted by the kernel\u0027s 1/4 limit)\nthen the stack occupies the address 0x80000000, and the PIE is mapped\nabove the address 0x40000000 instead, directly below the libraries. \nThis vulnerability effectively nullifies the offset2lib patch, and\nallows us to reuse our Debian 8 exploit against Debian 9 and 10. \n\n$ ./Linux_offset2lib\nRun #1... \nCVE-2017-1000370 triggered\n40076000-40078000 r-xp 00000000 00:26 25041 /tmp/Linux_offset2lib\n40078000-40079000 r--p 00001000 00:26 25041 /tmp/Linux_offset2lib\n40079000-4009b000 rw-p 00002000 00:26 25041 /tmp/Linux_offset2lib\n4009b000-400c0000 r-xp 00000000 fd:00 8463588 /usr/lib/ld-2.24.so\n400c0000-400c1000 r--p 00024000 fd:00 8463588 /usr/lib/ld-2.24.so\n400c1000-400c2000 rw-p 00025000 fd:00 8463588 /usr/lib/ld-2.24.so\n400c2000-400c4000 r--p 00000000 00:00 0 [vvar]\n400c4000-400c6000 r-xp 00000000 00:00 0 [vdso]\n400c6000-400c8000 rw-p 00000000 00:00 0\n400cf000-402a3000 r-xp 00000000 fd:00 8463595 /usr/lib/libc-2.24.so\n402a3000-402a4000 ---p 001d4000 fd:00 8463595 /usr/lib/libc-2.24.so\n402a4000-402a6000 r--p 001d4000 fd:00 8463595 /usr/lib/libc-2.24.so\n402a6000-402a7000 rw-p 001d6000 fd:00 8463595 /usr/lib/libc-2.24.so\n402a7000-402aa000 rw-p 00000000 00:00 0\n7fcf1000-bfcf2000 rw-p 00000000 00:00 0 [stack]\n\nCaveats\n\n- On Fedora and CentOS, this ld.so \"hwcap\" exploit fails against\n /usr/bin/passwd and /usr/bin/chage (but it works against all other\n SUID-root binaries) because of SELinux:\n\ntype=AVC msg=audit(1492091008.983:414): avc: denied { execute } for pid=2169 comm=\"passwd\" path=\"/var/tmp/a\" dev=\"dm-0\" ino=12828063 scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0\n\ntype=AVC msg=audit(1492092997.581:487): avc: denied { execute } for pid=2648 comm=\"chage\" path=\"/var/tmp/a\" dev=\"dm-0\" ino=12828063 scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0\n\n- It fails against recent versions of Sudo that specify an RPATH such as\n \"/usr/lib/sudo\": _dl_map_object() first searches for our LD_AUDIT\n library in RPATH, but open_path() fails to find our library in\n \"/usr/lib/sudo//../tmp/\" and crashes as soon as it reaches an\n overwritten hwcap-pointer. \n\n This problem can be solved by a 16-byte pattern \"///../../../tmp/\"\n (instead of the 8-byte pattern \"/../tmp/\") but the exploit\u0027s\n probability of success would be divided by two. \n\n- On Ubuntu, this ld.so \"hwcap\" exploit always fails, because of the\n following patch:\n\nDescription: pro-actively disable LD_AUDIT for setuid binaries, regardless\n of where the libraries are loaded from. This is to try to make sure that\n CVE-2010-3856 cannot sneak back in. Upstream is unlikely to take this,\n since it limits the functionality of LD_AUDIT. \nAuthor: Kees Cook \u003ckees@ubuntu.com\u003e\n\nIndex: eglibc-2.15/elf/rtld.c\n===================================================================\n--- eglibc-2.15.orig/elf/rtld.c 2012-05-09 10:05:29.456899131 -0700\n+++ eglibc-2.15/elf/rtld.c 2012-05-09 10:38:53.952009069 -0700\n@@ -2529,7 +2529,7 @@\n while ((p = (strsep) (\u0026str, \":\")) != NULL)\n if (p[0] != \u0027\\0\u0027\n \u0026\u0026 (__builtin_expect (! __libc_enable_secure, 1)\n- || strchr (p, \u0027/\u0027) == NULL))\n+ ))\n {\n /* This is using the local malloc, not the system malloc. The\n memory can never be freed. */\n\n========================================================================\nIV.1.4. ld.so \".dynamic\" exploit\n========================================================================\n\nTo exploit ld.so without the LD_AUDIT memory leak, we rely on a second\nvulnerability that we discovered in the offset2lib patch\n(CVE-2017-1000371):\n\nif we set RLIMIT_STACK to RLIM_INFINITY, and allocate nearly 1GB of\nstack memory (the maximum permitted by the kernel\u0027s 1/4 limit on the\nargument and environment strings) then the stack grows down to almost\n0x80000000, and because the PIE is mapped above 0x80000000, the minimum\ndistance between the end of the PIE\u0027s read-write segment and the start\nof the stack is 4KB (the stack guard-page). \n\n$ ./Linux_offset2lib 0x3f800000\nRun #1... \nRun #2... \nRun #3... \nRun #796... \nRun #797... \nRun #798... \nCVE-2017-1000371 triggered\n4007b000-400a0000 r-xp 00000000 fd:00 8463588 /usr/lib/ld-2.24.so\n400a0000-400a1000 r--p 00024000 fd:00 8463588 /usr/lib/ld-2.24.so\n400a1000-400a2000 rw-p 00025000 fd:00 8463588 /usr/lib/ld-2.24.so\n400a2000-400a4000 r--p 00000000 00:00 0 [vvar]\n400a4000-400a6000 r-xp 00000000 00:00 0 [vdso]\n400a6000-400a8000 rw-p 00000000 00:00 0\n400af000-40283000 r-xp 00000000 fd:00 8463595 /usr/lib/libc-2.24.so\n40283000-40284000 ---p 001d4000 fd:00 8463595 /usr/lib/libc-2.24.so\n40284000-40286000 r--p 001d4000 fd:00 8463595 /usr/lib/libc-2.24.so\n40286000-40287000 rw-p 001d6000 fd:00 8463595 /usr/lib/libc-2.24.so\n40287000-4028a000 rw-p 00000000 00:00 0\n8000a000-8000c000 r-xp 00000000 00:26 25041 /tmp/Linux_offset2lib\n8000c000-8000d000 r--p 00001000 00:26 25041 /tmp/Linux_offset2lib\n8000d000-8002f000 rw-p 00002000 00:26 25041 /tmp/Linux_offset2lib\n80030000-bf831000 rw-p 00000000 00:00 0 [heap]\n\nNote: in this example, the \"[stack]\" is incorrectly displayed as the\n\"[heap]\" by show_map_vma() (in fs/proc/task_mmu.c). \n\nThis completes Step 1: we clash the stack with the PIE\u0027s read-write\nsegment; we complete the remaining steps as in the \"hwcap\" exploit:\n\n- Step 2: we consume the initial stack expansion with 128KB of argv[]\n and envp[] pointers;\n\n- Step 3: we jump over the stack guard-page and into the PIE\u0027s\n read-write segment with llp_tmp\u0027s alloca() (in _dl_init_paths());\n\n- Step 4b: we smash the PIE\u0027s read-write segment with llp_tmp\u0027s\n good-write and bad-write (in _dl_init_paths()); we can smash the\n following sections:\n\n + .data and .bss: but we discarded this application-specific approach;\n\n + .got: although protected by Full RELRO (Full RELocate Read-Only,\n GNU_RELRO and BIND_NOW) the .got is still writable when we smash it\n in _dl_init_paths(); however, within ld.so, the .got is written to\n but never read from, and we therefore discarded this approach;\n\n + .dynamic: our favored approach. \n\nOn i386, the .dynamic section is an array of Elf32_Dyn structures (an\nint32 d_tag, and the union of uint32 d_val and uint32 d_ptr) that\ncontains entries such as:\n\n- DT_STRTAB, a pointer to the PIE\u0027s .dynstr section (a read-only string\n table): its d_tag (DT_STRTAB) is read (by elf_get_dynamic_info())\n before we smash it in _dl_init_paths(), but its d_ptr is read (by\n _dl_map_object_deps()) after we smash it in _dl_init_paths();\n\n- DT_NEEDED, an offset into the .dynstr section: the pathname of a\n dependent library that must be loaded by _dl_map_object_deps(). \n\nIf we overwrite the entire .dynamic section with the following 8-byte\npattern (an Elf32_Dyn structure):\n\n- a DT_NEEDED d_tag,\n\n- a d_val equal to half the address of our own string table on the stack\n (16MB of argument strings, enough to defeat the 8MB stack\n randomization),\n\nthen _dl_map_object_deps() reads the pathname of this dependent library\nfrom DT_STRTAB.d_ptr + DT_NEEDED.d_val = our_strtab/2 + our_strtab/2 =\nour_strtab, and loads our own library, as root. This 8-byte pattern is\nsimple, but poses two problems:\n\n- DT_NEEDED is an int32 equal to 1, but we smash the .dynamic section\n with a string copy that cannot contain null-bytes: to solve this first\n problem we use DT_AUXILIARY instead, which is equivalent but equal to\n 0x7ffffffd;\n\n- ld.so crashes before it returns from dl_main() (before it calls\n _dl_init() and executes our library\u0027s _init() constructor):\n\n . in _dl_map_object_deps() because of our DT_AUXILIARY entry;\n\n . in version_check_doit() because we overwrote the DT_VERNEED entry;\n\n . in _dl_relocate_object() because we overwrote the DT_REL, DT_RELSZ,\n and DT_RELCOUNT entries. \n\nTo solve this second problem, we could overwrite the .dynamic section\nwith a more complicated pattern that repairs these entries, but our\nexploit\u0027s probability of success would decrease significantly. \n\nInstead, we take control of ld.so\u0027s execution flow as soon as\n_dl_map_object_deps() loads our library:\n\n- our library contains three executable LOAD segments,\n\n- but only the first and last segments are sanity-checked by\n _dl_map_object_from_fd() and _dl_map_segments(),\n\n- and all segments except the first are mmap()ed with MAP_FIXED by\n _dl_map_segments(),\n\n- so we can mmap() our second segment anywhere -- we mmap() it on top of\n ld.so\u0027s executable segment,\n\n- and return into our own code (instead of ld.so\u0027s) as soon as this\n second mmap() system-call returns. \n\nProbabilities\n\nThe \"hwcap\" exploit taught us that this \".dynamic\" exploit\u0027s probability\nof success depends on:\n\n- the size of the cushion below the .dynamic section, which can absorb\n the excess of \"good-write\" without crashing: the padding bytes between\n the start of the PIE\u0027s read-write segment and the start of its first\n read-write section;\n\n- the size of the cushion above the .dynamic section, which can absorb\n the excess of \"good-write\" and \"bad-write\" without crashing: the .got,\n .data, and .bss sections. \n\nIf we guarantee that (cushion above .dynamic \u003e good-write + bad-write),\nthen the theoretical probability of success is approximately:\n\nMIN(cushion below .dynamic, good-write) / max stack randomization\n\nThe maximum size of the cushion below the .dynamic section is 4KB (one\npage) and hence the maximum probability of success is 4KB/8MB=1/2048. \nIn practice, on Ubuntu 16.04.2:\n\n- the highest probability is 1/2589 (/bin/su) and the lowest probability\n is 1/9225 (/usr/lib/eject/dmcrypt-get-device);\n\n- each run uses 1GB of memory and takes 1.5 seconds (on a 4GB Virtual\n Machine);\n\n- this ld.so \".dynamic\" exploit has a good chance of obtaining a\n root-shell after 2589 * 1.5 seconds ~= 1 hour. \n\n========================================================================\nIV.1.5. /bin/su\n========================================================================\n\nAs we were drafting this advisory, we discovered a general method for\ncompleting Step 1 (Clash) of the stack-clash exploitation: the Linux\nkernel limits the size of the command-line arguments and environment\nvariables to 1/4 of the RLIMIT_STACK, but it imposes this limit on the\nargument and environment strings, not on the argv[] and envp[] pointers\nto these strings (CVE-2017-1000365). \n\nOn i386, if we set RLIMIT_STACK to RLIM_INFINITY, the maximum number of\nargv[] and envp[] pointers is 1G (1/4 of the RLIMIT_STACK, divided by\n1B, the minimum size of an argument or environment string). In theory,\nthe maximum size of the initial stack is therefore 1G*(1B+4B)=5GB. In\npractice, this would exhaust the address-space and allows us to clash\nthe stack with the memory region that is mapped below, without an\napplication-specific memory leak. \n\nThis discovery allowed us to write alternative versions of our\nstack-clash exploits; for example:\n\n- an ld.so \"hwcap\" exploit against Ubuntu: we replace the LD_AUDIT\n memory leak with 2GB of stack memory (1GB of argument and environment\n strings, and 1GB of argv[] and envp[] pointers) and replace the\n LD_AUDIT library with an LD_PRELOAD library;\n\n- an ld.so \".dynamic\" exploit against systems vulnerable to offset2lib:\n we reach the end of the PIE\u0027s read-write segment with only 128MB of\n stack memory (argument and environment strings and pointers). \n\nThese proofs-of-concept demonstrate a general method for completing Step\n1 (Clash), but they are much slower than their original versions (10-20\nseconds per run) because they pass millions of argv[] and envp[]\npointers to execve(). \n\nMoreover, this discovery allowed us to exploit SUID binaries through\ngeneral methods that do not depend on application-specific or ld.so\nvulnerabilities; if a SUID binary calls setlocale(LC_ALL, \"\"); and\ngettext() (or a derivative such as strerror() or _()), then it is\nexploitable:\n\n- Step 1: we clash the stack with the heap through millions of argument\n and environment strings and pointers;\n\n- Step 2: we consume the initial stack expansion with 128KB of argument\n and environment pointers;\n\n- Step 3: we jump over the stack guard-page and into the heap with the\n alloca()tion of the LANGUAGE environment variable in gettext();\n\n- Step 4a: we smash the stack with the malloc()ation of the\n OUTPUT_CHARSET environment variable in gettext() and thus gain control\n of eip. \n\nFor example, we exploited Debian\u0027s /bin/su (from the shadow-utils): its\nmain() function calls setlocale() and save_caller_context(), which calls\ngettext() (through _()) if its stdin is not a tty. \n\nDebian 8.5\n\nDebian 8.5 is vulnerable to CVE-2016-3672: we set RLIMIT_STACK to\nRLIM_INFINITY and disable ASLR, clash the stack with the heap through\n2GB of argument and environment strings and pointers (1GB of strings,\n1GB of pointers), and return-into-libc\u0027s system() or __libc_dlopen():\n\n- the system() version uses 4GB of memory (2GB in the /bin/su process,\n and 2GB in the process fork()ed by system());\n\n- the __libc_dlopen() version uses only 2GB of memory, but ebp must\n point to our smashed data on the stack. \n\nDebian 8.6\n\nDebian 8.6 is vulnerable to offset2lib but not to CVE-2016-3672: we must\nbrute-force the libc\u0027s ASLR (8 bits of entropy), but we clash the stack\nwith the heap through only 128MB of argument and environment strings and\npointers -- this /bin/su exploit can be parallelized. \n\n========================================================================\nIV.1.6. Grsecurity/PaX\n========================================================================\n\nhttps://grsecurity.net/\n\nIn 2010, grsecurity/PaX introduced a configurable stack guard-page: its\nsize can be modified through /proc/sys/vm/heap_stack_gap and is 64KB by\ndefault (unlike the hard-coded 4KB stack guard-page in the vanilla\nkernel). \n\nUnfortunately, a 64KB stack guard-page is not large enough, and can be\njumped over with ld.so or gettext() (CVE-2017-1000377); for example, we\nwere able to gain eip control against Sudo, but we were unable to obtain\na root-shell or gain eip control against another application, because\ngrsecurity/PaX imposes the following security measures:\n\n- it restricts the RLIMIT_STACK of SUID binaries to 8MB, which prevents\n us from switching to the legacy bottom-up mmap() layout (Step 1);\n\n- it restricts the argument and environment strings to 512KB, which\n prevents us from clashing the stack through megabytes of command-line\n arguments and environment variables (Step 1);\n\n- it randomizes the PIE and libraries with 16 bits of entropy (instead\n of 8 bits in vanilla), which prevents us from brute-forcing the ASLR\n and returning-into-libc (Step 4a);\n\n- it implements /proc/sys/kernel/grsecurity/deter_bruteforce (enabled by\n default), which limits the number of SUID crashes to 1 every 15\n minutes (all Steps) and makes exploitation impossible. \n\nSudo\n\nThe vulnerability that we discovered in Sudo\u0027s get_process_ttyname()\n(CVE-2017-1000367) allows us to:\n\n- Step 1: clash the stack with 3GB of heap memory from the filesystem\n (directory pathnames) and bypass grsecurity/PaX\u0027s 512KB limit on the\n argument and environment strings;\n\n- Step 2: consume the 128KB of initial stack expansion with 3MB of\n recursive function calls and avoid grsecurity/PaX\u0027s 8MB restriction on\n the RLIMIT_STACK;\n\n- Step 3: jump over grsecurity/PaX\u0027s 64KB stack guard-page with a 128KB\n (MAX_ARG_STRLEN) alloca()tion of the LANGUAGE environment variable in\n gettext();\n\n- Step 4a: smash the stack with a 128KB (MAX_ARG_STRLEN) malloc()ation\n of the OUTPUT_CHARSET environment variable in gettext() -- the\n \"smashing-chunk\" -- and thus gain control of eip. \n\nIn Step 1, we nearly exhaust the address-space until finally malloc()\nswitches from brk() to 1MB mmap()s and reaches the start of the stack\nwith the very last 1MB mmap() that we allocate. The exact amount of\nmemory that we must allocate to reach the stack with our last 1MB mmap()\ndepends on the sum of three random variables: the 256MB randomization of\nthe stack, the 64MB randomization of the heap, and the 1MB randomization\nof the NULL region. \n\nTo maximize the probability of jumping over the stack guard-page, into\nour last 1MB mmap() below the stack, and overwriting a return-address on\nthe stack with our smashing-chunk:\n\n- (Step 1) we must allocate the mean amount of memory to reach the stack\n with our last 1MB mmap(): the sum of three uniform random variables is\n not uniform (https://en.wikipedia.org/wiki/Irwin-Hall_distribution),\n but the values within the 256MB-64MB-1MB=191MB plateau at the center\n of this bell-shaped probability distribution occur with a uniform and\n maximum probability of (1MB*64MB)/(1MB*64MB*256MB)=1/256MB;\n\n- (Step 1) the end of our last 1MB mmap() must be allocated at a\n distance within [stack guard-page (64KB), guard-page jump (128KB)]\n below the start of the stack: the guard-page jump (Step 3) then lands\n at a distance d within [0, guard-page jump - stack guard-page (64KB)]\n below the end of our last 1MB mmap();\n\n- (Step 4a) the end of our smashing-chunk must be allocated at the end\n of our last 1MB mmap(), above the landing-point of the guard-page\n jump: our smashing-chunk then overwrites a return-address on the\n stack, below the landing-point of the guard-page jump. \n\nIn theory, this probability is roughly:\n\nSUM(d = 1; d \u003c guard-page jump - stack guard-page; d++) d / (256MB*1MB)\n\n ~= ((guard-page jump - stack guard-page)^2 / 2) / (256MB*1MB)\n\n ~= 1 / 2^17\n\nIn practice, we tested this Sudo proof-of-concept on an i386 Debian 8.6\nprotected by the linux-grsec package from the jessie-backports, but we\nmanually disabled /proc/sys/kernel/grsecurity/deter_bruteforce:\n\n- it uses 3GB of memory, and 800K on-disk inodes;\n\n- it takes 5.5 seconds per run (on a 4GB Virtual Machine);\n\n- it has a good chance of gaining eip control after 2^17 * 5.5 seconds =\n 200 hours; in our test:\n\nPAX: From 192.168.56.1: execution attempt in: \u003cheap\u003e, 1b068000-a100d000 1b068000\nPAX: terminating task: /usr/bin/sudo( 1 ):25465, uid/euid: 1000/0, PC: 41414141, SP: b8844f30\nPAX: bytes at PC: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41\nPAX: bytes at SP-4: 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141\n\nHowever, brute-forcing the ASLR to obtain a root-shell would take ~1500\nyears and makes exploitation impossible. \n\nMoreover, if we enable /proc/sys/kernel/grsecurity/deter_bruteforce,\ngaining eip control would take ~1365 days, and obtaining a root-shell\nwould take thousands of years. \n\n========================================================================\nIV.1.7. 64-bit exploitation\n========================================================================\n\nIntroduction\n\nThe address-space of a 64-bit process is so vast that we initially\nthought it was impossible to clash the stack with another memory region;\nwe were wrong. \n\nLinux\u0027s execve() first randomizes the end of the mmap region (which\ngrows top-down by default) and then randomizes the end of the stack\nregion (which grows down, on x86). On amd64, the initial mmap-stack\ndistance (between the end of the mmap region and the end of the stack\nregion) is minimal when RLIMIT_STACK is lower than or equal to MIN_GAP\n(mmap_base() in arch/x86/mm/mmap.c), and then:\n\n- the end of the mmap region is equal to (as calculated by\n arch_pick_mmap_layout() in arch/x86/mm/mmap.c):\n\n mmap_end = TASK_SIZE - MIN_GAP - arch_mmap_rnd()\n\n where:\n\n . TASK_SIZE is the highest address of the user-space (0x7ffffffff000)\n\n . MIN_GAP = 128MB + stack_maxrandom_size()\n\n . stack_maxrandom_size() is ~16GB (or ~4GB if the kernel is vulnerable\n to CVE-2015-1593, but we do not consider this case here)\n\n . arch_mmap_rnd() is a random variable in the [0B,1TB] range\n\n- the end of the stack region is equal to (as calculated by\n randomize_stack_top() in fs/binfmt_elf.c):\n\n stack_end = TASK_SIZE - \"stack_rand\"\n\n where:\n\n . \"stack_rand\" is a random variable in the [0, stack_maxrandom_size()]\n range\n\n- the initial mmap-stack distance is therefore equal to:\n\n stack_end - mmap_end = MIN_GAP + arch_mmap_rnd() - \"stack_rand\"\n\n = 128MB + stack_maxrandom_size() - \"stack_rand\" + arch_mmap_rnd()\n\n = 128MB + StackRand + MmapRand\n\n where:\n\n . StackRand = stack_maxrandom_size() - \"stack_rand\", a random variable\n in the [0B,16GB] range\n\n . MmapRand = arch_mmap_rnd(), a random variable in the [0B,1TB] range\n\nConsequently, the minimum initial mmap-stack distance is only 128MB\n(CVE-2017-1000379), and:\n\n- On kernels vulnerable to offset2lib, the heap of a PIE (which is\n mapped at the end of the mmap region) is mapped below and close to the\n stack with a good probability (~1/700). We can therefore clash the\n stack with the heap in Step 1, jump over the stack guard-page and into\n the heap in Step 3, and smash the stack with the heap and gain control\n of rip in Step 4a (after 6 hours on average). However, because the\n addresses of all executable regions contain null-bytes, and because\n most of our stack-smashes in Step 4a are string operations (except the\n getaddrinfo() method), we were unable to transform such a rip control\n into arbitrary code execution. \n\n- On all kernels, either a PIE or ld.so is mapped directly below the\n stack with a good probability (~1/17000) -- the end of the PIE\u0027s or\n ld.so\u0027s read-write segment is then equal to the start of the stack\n guard-page. We can therefore adapt our ld.so \"hwcap\" exploit to amd64\n and obtain root privileges through most SUID binaries on most Linux\n distributions (after 5 hours on average). \n\nKernels vulnerable to offset2lib, local Exim proof-of-concept\n\nExim\u0027s binary is usually a PIE, mapped at the end of the mmap region;\nand the heap, which always grows up and is randomized above the end of\nthe binary, is therefore randomized above the end of the mmap region\n(arch_randomize_brk() in arch/x86/kernel/process.c):\n\n heap_start = mmap_end + \"heap_rand\"\n\nwhere \"heap_rand\" is a random variable in the [0B,32MB] range\n(negligible and ignored here). For example, on Debian 8.5:\n\n# cat /proc/\"`pidof -s /usr/sbin/exim4`\"/maps\n... \n7fa6410d6000-7fa6411c8000 r-xp 00000000 08:01 14574 /usr/sbin/exim4\n7fa6413b4000-7fa6413bd000 rw-p 00000000 00:00 0\n7fa6413c5000-7fa6413c7000 rw-p 00000000 00:00 0\n7fa6413c7000-7fa6413c9000 r--p 000f1000 08:01 14574 /usr/sbin/exim4\n7fa6413c9000-7fa6413d2000 rw-p 000f3000 08:01 14574 /usr/sbin/exim4\n7fa6413d2000-7fa6413d7000 rw-p 00000000 00:00 0\n7fa641b34000-7fa641b76000 rw-p 00000000 00:00 0 [heap]\n7ffdf3e53000-7ffdf3ed6000 rw-p 00000000 00:00 0 [stack]\n7ffdf3f3c000-7ffdf3f3e000 r-xp 00000000 00:00 0 [vdso]\n7ffdf3f3e000-7ffdf3f40000 r--p 00000000 00:00 0 [vvar]\nffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]\n\nTo reach the start of the stack with the end of the heap (through the -p\nmemory leak in Exim) in Step 1 of our stack-clash, we must minimize the\ninitial heap-stack distance, and hence the initial mmap-stack distance,\nand set RLIMIT_STACK to MIN_GAP (~16GB). This limits the size of our -p\nargument strings on the stack to 16GB/4=4GB, and because we then leak\nthe same amount of heap memory through -p, the initial heap-stack\ndistance must be:\n\n- longer than 4GB (the stack must be able to contain the -p argument\n strings);\n\n- shorter than 8GB (the end of the heap must be able to reach the start\n of the stack during the -p memory leak). \n\nThe initial heap-stack distance (approximately the initial mmap-stack\ndistance, 128MB + StackRand + MmapRand, but we ignore the 128MB term\nhere) follows a trapezoidal Irwin-Hall distribution, and the [4GB,8GB]\nrange is within the first non-uniform area of this trapezoid, so the\nprobability that the initial heap-stack distance is in this range is:\n\n SUM(d = 4GB; d \u003c 8GB; d++) d / (16GB * 1TB)\n\n = SUM(d = 0; d \u003c 4GB; d++) (4GB + d) / (16GB * 1TB)\n\n = SUM(d = 0; d \u003c 2^32; d++) (2^32 + d) / (2^34 * 2^40)\n\n ~= ((2^32)*(2^32) + (2^32)*(2^32) / 2) / (2^74)\n\n ~= 3 / 2^11\n\n ~= 1 / 682\n\nThe probability of gaining rip control after the heap reaches the stack\nis ~1/16 (as calculated by a 64-bit version of the small helper program\npresented in IV.1.1.), and the final probability of gaining rip control\nwith our local Exim proof-of-concept is:\n\n (3 / 2^11) * (1/16) ~= 1 / 10922\n\nOn our 8GB Debian 8.7 test machine, this proof-of-concept takes roughly\n2 seconds per run, and has a good chance of gaining rip control after\n10922 * 2 seconds ~= 6 hours:\n\n# gdb /usr/sbin/exim4 core.6049\nGNU gdb (Debian 7.7.1+dfsg-5) 7.7.1\n... \nThis GDB was configured as \"x86_64-linux-gnu\". \nCore was generated by `/usr/sbin/exim4 -p0000000000000000000000000000000000000000000000000000000000000\u0027. \nProgram terminated with signal SIGSEGV, Segmentation fault. \n#0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:41\n41 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such file or directory. \n(gdb) x/i $rip\n=\u003e 0x7ffab1be7061 \u003c__memcpy_sse2_unaligned+65\u003e: retq\n(gdb) x/xg $rsp\n0x7ffb9b294a48: 0x4141414141414141\n\nKernels vulnerable to offset2lib, ld.so \".dynamic\" exploit\n\nSince kernels vulnerable to offset2lib map PIEs below and close to the\nstack, we tried to adapt our ld.so \".dynamic\" exploit to amd64. MIN_GAP\nguarantees a minimum distance of 128MB between the theoretical end of\nthe mmap region and the end of the stack, but the stack then grows down\nto store the argument and environment strings, and may therefore occupy\nthe theoretical end of the mmap region (where nothing has been mapped\nyet). Consequently, the end of the mmap region (where the PIE will be\nmapped) slides down to the first available address, directly below the\nstack guard-page and the initial stack expansion (described in II.3.2.):\n\n7ffbb7e51000-7ffbb7e53000 r-xp 00000000 fd:03 4465810 /tmp/test64\n... \n7ffbb8053000-7ffbb808c000 rw-p 00002000 fd:03 4465810 /tmp/test64\n7ffbb808d000-7ffc180ae000 rw-p 00000000 00:00 0 [heap]\nffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]\n\nNote: in this example, the \"[stack]\" is, again, incorrectly displayed as\nthe \"[heap]\" by show_map_vma() (in fs/proc/task_mmu.c). \n\nThis layout is ideal for our stack-clash exploits, but poses an\nunexpected problem: because the PIE is mapped directly below the stack,\nthe stack cannot grow anymore, and the only free stack space is the\ninitial stack expansion (128KB) minus the argv[] and envp[] pointers\n(which are stored there, as mentioned in II.3.2.):\n\n- on the one hand, many argv[] and envp[] pointers, and hence many\n argument and environment strings, result in a higher probability of\n mapping the PIE directly below the stack;\n\n- on the other hand, many argv[] and envp[] pointers consume most of the\n initial stack expansion and do not leave enough free stack space for\n ld.so to operate. \n\nIn practice, we pass 96KB of argv[] pointers to execve(), thus leaving\n32KB of free stack space for ld.so, and since the size of a pointer is\n8B, and the maximum size of an argument string is 128KB, we also pass\n96KB/8B*128KB=1.5GB of argument strings to execve(). The resulting\nprobability of mapping the PIE directly below the stack is:\n\n SUM(s = 0; s \u003c 1.5GB - 128MB; s++) s / (16GB * 1TB)\n\n ~= ((1.5GB - 128MB)^2 / 2) / (16GB * 1TB)\n\n ~= 1 / 17331\n\nOn a 4GB Virtual Machine, each run takes 1 second, and 17331 runs take\nroughly 5 hours. But we cannot add more uncertainty to this exploit, and\nbecause of the problems discussed in IV.1.4. (null-bytes in DT_NEEDED,\nbut also in DT_AUXILIARY on 64-bit, etc), we were unable to overwrite\nthe .dynamic section with a pattern that does not significantly decrease\nthis exploit\u0027s probability of success. \n\nAll kernels, ld.so \"hwcap\" exploit\n\nDespite this failure, we had an intuition: when the PIE is mapped\ndirectly below the stack, the stack layout should be deterministic --\nrsp should point into the 128KB of initial stack expansion, at a 32KB\noffset above the start of the stack, and the only entropy should be the\n8KB of sub-page randomization within the stack (arch_align_stack() in\narch/x86/kernel/process.c). The following output of our small test\nprogram confirmed this intuition (the fourth field is the distance\nbetween the start of the stack and our main()\u0027s rsp when the PIE is\nmapped directly below the stack):\n\n$ grep -w sp test64.out | sort -nk4\nsp 0x7ffbc271ff38 -\u003e 28472\nsp 0x7ffbb95ccff8 -\u003e 28664\nsp 0x7ffbaf062678 -\u003e 30328\nsp 0x7ffbb08736e8 -\u003e 30440\nsp 0x7ffbbc616d18 -\u003e 32024\nsp 0x7ffbc1a0fdb8 -\u003e 32184\nsp 0x7ffbb9c28ff8 -\u003e 32760\nsp 0x7ffbdbf4c178 -\u003e 33144\nsp 0x7ffbb39bc1c8 -\u003e 33224\nsp 0x7ffbebb86838 -\u003e 34872\n\nSurprisingly, the output of this test program contained additional\nvaluable information:\n\n7ffbb7e51000-7ffbb7e53000 r-xp 00000000 fd:03 4465810 /tmp/test64\n7ffbb8034000-7ffbb8037000 rw-p 00000000 00:00 0\n7ffbb804d000-7ffbb804e000 rw-p 00000000 00:00 0\n7ffbb804e000-7ffbb8050000 r--p 00000000 00:00 0 [vvar]\n7ffbb8050000-7ffbb8052000 r-xp 00000000 00:00 0 [vdso]\n7ffbb8052000-7ffbb8053000 r--p 00001000 fd:03 4465810 /tmp/test64\n7ffbb8053000-7ffbb808c000 rw-p 00002000 fd:03 4465810 /tmp/test64\n7ffbb808d000-7ffc180ae000 rw-p 00000000 00:00 0 [heap]\nffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]\n\n- the distance between the end of the read-execute segment of our test\n program and the start of its read-only and read-write segments is\n approximately 2MB; indeed, for every ELF on amd64:\n\n$ readelf -a /usr/bin/su | grep -wA1 LOAD\n LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000\n 0x00000000000061b4 0x00000000000061b4 R E 200000\n LOAD 0x0000000000006888 0x0000000000206888 0x0000000000206888\n 0x0000000000000798 0x00000000000007d0 RW 200000\n\n$ readelf -a /lib64/ld-linux-x86-64.so.2 | grep -wA1 LOAD\n LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000\n 0x000000000001fad0 0x000000000001fad0 R E 200000\n LOAD 0x000000000001fb60 0x000000000021fb60 0x000000000021fb60\n 0x000000000000141c 0x00000000000015e8 RW 200000\n\n- several objects are actually mapped inside this ~2MB hole: [vdso],\n [vvar], and two anonymous mappings (7ffbb804d000-7ffbb804e000 and\n 7ffbb8034000-7ffbb8037000). \n\nThis discovery allowed us to adapt our ld.so \"hwcap\" exploit to amd64:\n\n- we choose hardware-capabilities that are small enough to be mapped\n inside this ~2MB hole, but large enough to defeat the 8KB sub-page\n randomization of the stack;\n\n- we jump over the stack guard-page, and over the read-only and\n read-write segments of the PIE, and exploit ld.so as we did on i386. \n\nThis exploit\u0027s probability of success is therefore 1 when the PIE is\nmapped directly below the stack, and its final probability of success is\n~1/17331: it takes 1 second per run, and has a good chance of obtaining\na root-shell after 5 hours. Moreover, it works on all kernels: if a SUID\nbinary is not a PIE, or if the kernel is not vulnerable to offset2lib,\nwe simply jump over ld.so\u0027s read-write segment, instead of the PIE\u0027s. \nFor example, on Fedora 25, when the exploit succeeds and loads our own\nlibrary /var/tmp/a (the 7ffbabbef000-7ffbabca7000 mapping contains the\nhardware-capabilities that we smash):\n\n55a0c9e8d000-55a0c9e91000 r-xp 00000000 fd:00 112767 /usr/libexec/cockpit-polkit\n55a0ca091000-55a0ca093000 rw-p 00004000 fd:00 112767 /usr/libexec/cockpit-polkit\n7ffbab603000-7ffbab604000 r-xp 00000000 fd:00 4866583 /var/tmp/a\n7ffbab604000-7ffbab803000 ---p 00001000 fd:00 4866583 /var/tmp/a\n7ffbab803000-7ffbab804000 r--p 00000000 fd:00 4866583 /var/tmp/a\n7ffbab804000-7ffbaba86000 rw-p 00000000 00:00 0\n7ffbaba86000-7ffbabaab000 r-xp 00000000 fd:00 4229637 /usr/lib64/ld-2.24.so\n7ffbabbef000-7ffbabca7000 rw-p 00000000 00:00 0\n7ffbabca7000-7ffbabca9000 r--p 00000000 00:00 0 [vvar]\n7ffbabca9000-7ffbabcab000 r-xp 00000000 00:00 0 [vdso]\n7ffbabcab000-7ffbabcad000 rw-p 00025000 fd:00 4229637 /usr/lib64/ld-2.24.so\n7ffbabcad000-7ffbabcae000 rw-p 00000000 00:00 0\n7ffbabcaf000-7ffc0bcf0000 rw-p 00000000 00:00 0 [stack]\nffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]\n\n========================================================================\nIV.2. OpenBSD\n========================================================================\n\n========================================================================\nIV.2.1. Maximum RLIMIT_STACK vulnerability (CVE-2017-1000372)\n========================================================================\n\nThe OpenBSD kernel limits the maximum size of the user-space stack\n(RLIMIT_STACK) to MAXSSIZ (32MB); the execve() system-call allocates a\nMAXSSIZ memory region for the stack and divides it in two:\n\n- the second part, effectively the user-space stack, is mapped\n PROT_READ|PROT_WRITE at the end of this stack memory region, and\n occupies RLIMIT_STACK bytes (by default 8MB for root processes, and\n 4MB for user processes);\n\n- the first part, effectively a large stack guard-page, is mapped\n PROT_NONE at the start of this stack memory region, and occupies\n MAXSSIZ - RLIMIT_STACK bytes. \n\nUnfortunately, we discovered that if an attacker sets RLIMIT_STACK to\nMAXSSIZ, he eliminates the PROT_NONE part of the stack region, and hence\nthe stack guard-page itself (CVE-2017-1000372). For example:\n\n# sh -c \u0027ulimit -S -s; procmap -a -P\u0027\n8192\nStart End Size Offset rwxpc RWX I/W/A Dev Inode - File\n... \n14cf6000-14cfafff 20k 00000000 r-xp+ (rwx) 1/0/0 00:03 52375 - /usr/sbin/procmap [0xdb29ce10]\n... \n84a7b000-84a7bfff 4k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ anon ]\ncd7db000-cefdafff 24576k 00000000 ---p+ (rwx) 1/0/0 00:00 0 - [ stack ]\ncefdb000-cf7cffff 8148k 00000000 rw-p+ (rwx) 1/0/0 00:00 0 - [ stack ]\ncf7d0000-cf7dafff 44k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ stack ]\n total 10348k\n\n# sh -c \u0027ulimit -S -s `ulimit -H -s`; procmap -a -P\u0027\nStart End Size Offset rwxpc RWX I/W/A Dev Inode - File\n... \n1a47f000-1a483fff 20k 00000000 r-xp+ (rwx) 1/0/0 00:03 52375 - /usr/sbin/procmap [0xdb29ce10]\n... \n8a3c8000-8a3c9fff 8k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ anon ]\ncd7c9000-cf7bffff 32732k 00000000 rw-p+ (rwx) 1/0/0 00:00 0 - [ stack ]\ncf7c0000-cf7c8fff 36k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ stack ]\n total 33992k\n\nA remote attacker cannot exploit this vulnerability, because he cannot\nmodify RLIMIT_STACK; but a local attacker can set RLIMIT_STACK to\nMAXSSIZ, and:\n\n- Step 1: malloc()ate almost 2GB of heap memory, until the heap reaches\n the start of the stack region;\n\n- Steps 2 and 3: consume MAXSSIZ (32MB) of stack memory, until the\n stack-pointer reaches the start of the stack region (Step 2) and moves\n into the heap (Step 3);\n\n- Step 4: smash the stack with the heap (Step 4a) or smash the heap with\n the stack (Step 4b). \n\n========================================================================\nIV.2.2. Recursive qsort() vulnerability (CVE-2017-1000373)\n========================================================================\n\nTo complete Step 2, a recursive function is needed, and the first\npossibly recursive function that we investigated is qsort(). On the one\nhand, glibc\u0027s _quicksort() function (in stdlib/qsort.c) is non-recursive\n(iterative): it uses a small, specialized stack of partition structures\n(two pointers, low and high), and guarantees that no more than 32\npartitions (on i386) or 64 partitions (on amd64) are pushed onto this\nstack, because it always pushes the larger of two sub-partitions and\niterates on the smaller partition. \n\nOn the other hand, BSD\u0027s qsort() function is recursive: it always\nrecurses on the first sub-partition, and iterates on the second\nsub-partition; but instead, it should always recurse on the smaller\nsub-partition, and iterate on the larger sub-partition (CVE-2017-1000373\nin OpenBSD, CVE-2017-1000378 in NetBSD, and CVE-2017-1082 in FreeBSD). \n\nIn theory, because BSD\u0027s qsort() is not randomized, an attacker can\nconstruct a pathological input array of N elements that causes qsort()\nto deterministically recurse N times. In practice, because this qsort()\nuses the median-of-three medians-of-three selection of a pivot element\n(the \"ninther\"), our attack constructs an input array of N elements that\ncauses qsort() to recurse N/4 times. \n\n========================================================================\nIV.2.3. /usr/bin/at proof-of-concept\n========================================================================\n\n/usr/bin/at is SGID-crontab (which can be escalated to full root\nprivileges) because it must be able to create (\"at -t\"), list (\"at -l\"),\nand remove (\"at -r\") job-files in the /var/cron/atjobs directory:\n\n-r-xr-sr-x 4 root crontab 31376 Jul 26 2016 /usr/bin/at\ndrwxrwx--T 2 root crontab 512 Jul 26 2016 /var/cron/atjobs\n\nTo demonstrate that OpenBSD\u0027s RLIMIT_STACK and qsort() vulnerabilities\ncan be transformed into powerful primitives such as heap corruption, we\ndeveloped a proof-of-concept against \"at -l\" (the list_jobs() function):\n\n- Step 1 (Clash): first, list_jobs() malloc()ates an atjob structure for\n each file in /var/cron/atjobs -- if we create 40M job-files, then the\n heap reaches the stack, but we do not exhaust the address-space;\n\n- Steps 2 and 3 (Run and Jump): second, list_jobs() qsort()s the\n malloc()ated jobs -- if we construct their time-stamps with our\n qsort() attack, then we can cause qsort() to recurse 40M/4=10M times\n and consume at least 10M*4B=40MB of stack memory (each recursive call\n to qsort() consumes at least 4B, the return-address) and move the\n stack-pointer into the heap;\n\n- Step 4b (Smash the heap with the stack): last, list_jobs() free()s the\n malloc()ated jobs, and abort()s with an error message -- OpenBSD\u0027s\n hardened malloc() implementation detects that the heap has been\n corrupted by the last recursive calls to qsort(). \n\nThis naive version of our /usr/bin/at proof-of-concept poses two major\nproblems:\n\n- Our pathological input array of N=40M elements cannot be sorted (Step\n 2 never finishes because it exhibits qsort()\u0027s worst-case behavior,\n N^2). To solve this problem, we divide the input array in two:\n\n . the first, pathological part contains only n=(33MB/176B)*4=768K\n elements that are needed to complete Steps 2 and 3, and cause\n qsort() to recurse n/4 times and consume (n/4)*176B=33MB of stack\n memory (MAXSSIZ+1MB) as each recursive call to qsort() consumes 176B\n of stack memory;\n\n . the second, innocuous part contains the remaining N-n=39M elements\n that are needed to complete Step 1, but not Steps 2 and 3, and are\n therefore swapped into the second, iterative partition of the first\n recursive call to qsort(). \n\n- We were unable to create 40M files in /var/cron/atjobs: after one\n week, OpenBSD\u0027s default filesystem (ffs) had created only 4M files,\n and the rate of file creation had dropped from 25 files/second to 4\n files/second. We did not solve this problem, but nevertheless wanted\n to validate our proof-of-concept:\n\n . we transformed it into an LD_PRELOAD library that intercepts calls\n to readdir() and fstatat(), and pretends that our 40M files in\n /var/cron/atjobs exist;\n\n . we made /var/cron/atjobs world-readable and LD_PRELOADed our library\n into a non-SGID copy of /usr/bin/at;\n\n . after about an hour, \"at\" reports random heap corruptions:\n\n# chmod o+r /var/cron/atjobs\n# chmod o+r /var/cron/at.deny\n\n$ ulimit -c 0\n$ ulimit -S -d `ulimit -H -d`\n$ ulimit -S -s `ulimit -H -s`\n$ ulimit -S -a\n... \ncoredump(blocks) 0\ndata(kbytes) 3145728\nstack(kbytes) 32768\n... \n$ cp /usr/bin/at . \n\n$ LD_PRELOAD=./OpenBSD_at.so ./at -l -v -q x \u003e /dev/null\ninitializing jobkeys\nfinalizing jobkeys\nreading jobs\n10%\n20%\n30%\n40%\n50%\n60%\n70%\n80%\n90%\n100%\nsorting jobs\nat(78717) in free(): error: chunk info corrupted\nAbort trap\n\n$ LD_PRELOAD=./OpenBSD_at.so ./at -l -v -q x \u003e /dev/null\ninitializing jobkeys\nfinalizing jobkeys\nreading jobs\n10%\n20%\n30%\n40%\n50%\n60%\n70%\n80%\n90%\n100%\nsorting jobs\nat(14184) in free(): error: modified chunk-pointer 0xcd6d0120\nAbort trap\n\n========================================================================\nIV.3. NetBSD\n========================================================================\n\nLike OpenBSD, NetBSD is vulnerable to the maximum RLIMIT_STACK\nvulnerability (CVE-2017-1000374): if a local attacker sets RLIMIT_STACK\nto MAXSSIZ, he eliminates the PROT_NONE part of the stack region -- the\nstack guard-page itself. Unlike OpenBSD, however, NetBSD:\n\n- defines MAXSSIZ to 64MB on i386 (128MB on amd64);\n\n- maps the run-time link-editor ld.so directly below the stack region,\n even if ASLR is enabled (CVE-2017-1000375):\n\n$ sh -c \u0027ulimit -S -s; pmap -a -P\u0027\n2048\nStart End Size Offset rwxpc RWX I/W/A Dev Inode - File\n08048000-0804dfff 24k 00000000 r-xp+ (rwx) 1/0/0 00:00 21706 - /usr/bin/pmap [0xc5c8f0b8]\n... \nbbbee000-bbbfefff 68k 00000000 r-xp+ (rwx) 1/0/0 00:00 107525 - /libexec/ld.elf_so [0xc535f580]\nbbbff000-bbbfffff 4k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ anon ]\nbbc00000-bf9fffff 63488k 00000000 ---p+ (rwx) 1/0/0 00:00 0 - [ stack ]\nbfa00000-bfbeffff 1984k 00000000 rw-p+ (rwx) 1/0/0 00:00 0 - [ stack ]\nbfbf0000-bfbfffff 64k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ stack ]\n total 9528k\n\n$ sh -c \u0027ulimit -S -s `ulimit -H -s`; pmap -a -P\u0027\nStart End Size Offset rwxpc RWX I/W/A Dev Inode - File\n08048000-0804dfff 24k 00000000 r-xp+ (rwx) 1/0/0 00:00 21706 - /usr/bin/pmap [0xc5c8f0b8]\n... \nbbbee000-bbbfefff 68k 00000000 r-xp+ (rwx) 1/0/0 00:00 107525 - /libexec/ld.elf_so [0xc535f580]\nbbbff000-bbbfffff 4k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ anon ]\nbbc00000-bfbeffff 65472k 00000000 rw-p+ (rwx) 1/0/0 00:00 0 - [ stack ]\nbfbf0000-bfbfffff 64k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ stack ]\n total 73016k\n\n# cp /usr/bin/pmap . \n# paxctl +A ./pmap\n# sh -c \u0027ulimit -S -s `ulimit -H -s`; ./pmap -a -P\u0027\nStart End Size Offset rwxpc RWX I/W/A Dev Inode - File\n08048000-0804dfff 24k 00000000 r-xp+ (rwx) 1/0/0 00:00 172149 - /tmp/pmap [0xc5cb3c64]\n... \nbbbee000-bbbfefff 68k 00000000 r-xp+ (rwx) 1/0/0 00:00 107525 - /libexec/ld.elf_so [0xc535f580]\nbbbff000-bbbfffff 4k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ anon ]\nbbc00000-bf1bffff 55040k 00000000 rw-p+ (rwx) 1/0/0 00:00 0 - [ stack ]\nbf1c0000-bf1cefff 60k 00000000 rw-p- (rwx) 1/0/0 00:00 0 - [ stack ]\n total 62580k\n\nConsequently, a local attacker can set RLIMIT_STACK to MAXSSIZ,\neliminate the stack guard-page, and:\n\n- skip Step 1, because ld.so\u0027s read-write segment is naturally mapped\n directly below the stack region;\n\n- Steps 2 and 3: consume 64MB (MAXSSIZ) of stack memory (for example,\n through the recursive qsort() vulnerability, CVE-2017-1000378) until\n the stack-pointer reaches the start of the stack region (Step 2) and\n moves into ld.so\u0027s read-write segment (Step 3);\n\n- Step 4b: smash ld.so\u0027s read-write segment with the stack. \n\nWe did not try to exploit this vulnerability, nor did we search for a\nvulnerable SUID or SGID binary, but we wrote a simple proof-of-concept,\nand some of the following crashes may be exploitable:\n\n$ sh -c \u0027ulimit -S -s `ulimit -H -s`; ./NetBSD_CVE-2017-1000375 0x04000000\u0027\n[1] Segmentation fault ./NetBSD_CVE-201... \n\n$ sh -c \u0027ulimit -S -s `ulimit -H -s`; ./NetBSD_CVE-2017-1000375 0x03000000\u0027\n\n... \n\n$ sh -c \u0027ulimit -S -s `ulimit -H -s`; ./NetBSD_CVE-2017-1000375 0x03ec5000\u0027\n\n$ sh -c \u0027ulimit -S -s `ulimit -H -s`; ./NetBSD_CVE-2017-1000375 0x03ec5400\u0027\n[1] Segmentation fault ./NetBSD_CVE-201... \n\n$ sh -c \u0027ulimit -S -s `ulimit -H -s`; gdb ./NetBSD_CVE-2017-1000375\u0027\nGNU gdb (GDB) 7.7.1\n... \n(gdb) run 0x03ec5400\nProgram received signal SIGSEGV, Segmentation fault. \n0xbbbf448d in _rtld_symlook_default () from /usr/libexec/ld.elf_so\n(gdb) x/i $eip\n=\u003e 0xbbbf448d \u003c_rtld_symlook_default+185\u003e: mov %edx,(%esi,%edi,4)\n(gdb) info registers\nesi 0xbabae890 -1162155888\nedi 0x0 0\n... \n(gdb) run 0x03ec5800\nProgram received signal SIGSEGV, Segmentation fault. \n0xbbbf4465 in _rtld_symlook_default () from /usr/libexec/ld.elf_so\n(gdb) x/i $eip\n=\u003e 0xbbbf4465 \u003c_rtld_symlook_default+145\u003e: mov 0x4(%ecx),%edx\n(gdb) info registers\necx 0x41414141 1094795585\n... \n(gdb) run 0x03ec5c00\nProgram received signal SIGSEGV, Segmentation fault. \n0xbbbf4408 in _rtld_symlook_default () from /usr/libexec/ld.elf_so\n(gdb) x/i $eip\n=\u003e 0xbbbf4408 \u003c_rtld_symlook_default+52\u003e: mov (%eax),%esi\n(gdb) info registers\neax 0x41414141 1094795585\n... \n\n========================================================================\nIV.4. FreeBSD\n========================================================================\n\n========================================================================\nIV.4.1. setrlimit() RLIMIT_STACK vulnerability (CVE-2017-1085)\n========================================================================\n\nFreeBSD\u0027s kern_proc_setrlimit() function contains the following comment\nand code:\n\n /*\n * Stack is allocated to the max at exec time with only\n * \"rlim_cur\" bytes accessible. If stack limit is going\n * up make more accessible, if going down make inaccessible. \n */\n if (limp-\u003erlim_cur != oldssiz.rlim_cur) {\n ... \n if (limp-\u003erlim_cur \u003e oldssiz.rlim_cur) {\n prot = p-\u003ep_sysent-\u003esv_stackprot;\n size = limp-\u003erlim_cur - oldssiz.rlim_cur;\n addr = p-\u003ep_sysent-\u003esv_usrstack -\n limp-\u003erlim_cur;\n } else {\n prot = VM_PROT_NONE;\n size = oldssiz.rlim_cur - limp-\u003erlim_cur;\n addr = p-\u003ep_sysent-\u003esv_usrstack -\n oldssiz.rlim_cur;\n }\n ... \n (void)vm_map_protect(\u0026p-\u003ep_vmspace-\u003evm_map,\n addr, addr + size, prot, FALSE);\n }\n\nOpenBSD\u0027s and NetBSD\u0027s dosetrlimit() function contains the same comment,\nwhich accurately describes the layout of their user-space stack region. \nUnfortunately, FreeBSD\u0027s kern_proc_setrlimit() comment and code are\nincorrect, as hinted at in exec_new_vmspace():\n\n/*\n * Destroy old address space, and allocate a new stack\n * The new stack is only SGROWSIZ large because it is grown\n * automatically in trap.c. \n */\n\nand vm_map_stack_locked():\n\n /*\n * We initially map a stack of only init_ssize. We will grow as\n * needed later. \n\nwhere init_ssize is SGROWSIZ (128KB), not MAXSSIZ (64MB on i386),\nbecause \"init_ssize = (max_ssize \u003c growsize) ? max_ssize : growsize;\"\n(and max_ssize is MAXSSIZ, and growsize is SGROWSIZ). \n\nAs a result, if a program calls setrlimit() to increase RLIMIT_STACK,\nvm_map_protect() may turn a read-only memory region below the stack into\na read-write region (CVE-2017-1085), as demonstrated by the following\nproof-of-concept:\n\n% ./FreeBSD_CVE-2017-1085\nSegmentation fault\n\n% ./FreeBSD_CVE-2017-1085 setrlimit to the max\nchar at 0xbd155000: 41\n\n========================================================================\nIV.4.2. Stack guard-page disabled by default (CVE-2017-1083)\n========================================================================\n\nThe FreeBSD kernel implements a 4KB stack guard-page, and recent\nversions of the FreeBSD Installer offer it as a system hardening option. \nUnfortunately, it is disabled by default (CVE-2017-1083):\n\n% sysctl security.bsd.stack_guard_page\nsecurity.bsd.stack_guard_page: 0\n\n========================================================================\nIV.4.3. Stack guard-page vulnerabilities (CVE-2017-1084)\n========================================================================\n\n- If FreeBSD\u0027s stack guard-page is enabled, its entire logic is\n implemented in vm_map_growstack(): this function guarantees a minimum\n distance of 4KB (the stack guard-page) between the start of the stack\n and the end of the memory region that is mapped below (but the stack\n guard-page is not physically mapped into the address-space). \n\n Unfortunately, this guarantee is given only when the stack grows down\n and clashes with the memory region mapped below, but not if the memory\n region mapped below grows up and clashes with the stack: this\n vulnerability effectively eliminates the stack guard-page\n (CVE-2017-1084). In our proof-of-concept:\n\n . we allocate anonymous mmap()s of 4KB, until the end of an anonymous\n mmap() reaches the start of the stack [Step 1];\n\n . we call a recursive function until the stack-pointer reaches the\n start of the stack and moves into the anonymous mmap() directly\n below [Step 2];\n\n . but we do not jump over the stack guard-page, because each call to\n the recursive function allocates (and fully writes to) a 1KB\n stack-based buffer [Step 3];\n\n . and we do not crash into the stack guard-page, because CVE-2017-1084\n has effectively eliminated the stack guard-page in Step 1. \n\n# sysctl security.bsd.stack_guard_page=1\nsecurity.bsd.stack_guard_page: 0 -\u003e 1\n\n% ./FreeBSD_CVE-2017-FGPU\nchar at 0xbfbde000: 41\n\n- vm_map_growstack() implements most of the stack guard-page logic in\n the following code:\n\n /*\n * Growing downward. \n */\n /* Get the preliminary new entry start value */\n addr = stack_entry-\u003estart - grow_amount;\n\n /*\n * If this puts us into the previous entry, cut back our\n * growth to the available space. Also, see the note above. \n */\n if (addr \u003c end) {\n stack_entry-\u003eavail_ssize = max_grow;\n addr = end;\n if (stack_guard_page)\n addr += PAGE_SIZE;\n }\n\n where:\n\n . addr is the new start of the stack;\n\n . stack_entry-\u003estart is the old start of the stack;\n\n . grow_amount is the size of the stack expansion;\n\n . end is the end of the memory region below the stack. \n\n Unfortunately, the \"addr \u003c end\" test should be \"addr \u003c= end\": if addr,\n the new start of the stack, is equal to end, the end of the memory\n region mapped below, then the stack guard-page is eliminated\n (CVE-2017-1084). In our proof-of-concept:\n\n . we allocate anonymous mmap()s of 4KB, until the end of an anonymous\n mmap() reaches a randomly chosen distance below the start of the\n stack [Step 1];\n\n . we call a recursive function until the stack-pointer reaches the\n start of the stack, and the stack expansion reaches the end of the\n anonymous mmap() below [Step 2];\n\n . we do not jump over the stack guard-page, because each call to the\n recursive function allocates (and fully writes to) a 1KB stack-based\n buffer [Step 3];\n\n . and we crash into the stack guard-page most of the time;\n\n . but we survive with a probability of 4KB/128KB=1/32 (grow_amount is\n always a multiple of SGROWSIZ, 128KB) because CVE-2017-1084 has\n effectively eliminated the stack guard-page in Step 2. \n\n% sysctl security.bsd.stack_guard_page\nsecurity.bsd.stack_guard_page: 1\n\n% sh -c \u0027while true; do ./FreeBSD_CVE-2017-FGPE; done\u0027\nSegmentation fault\nchar at 0xbe45e000: 41; final dist 6097 (24778705)\nSegmentation fault\nSegmentation fault\nSegmentation fault\n... \nSegmentation fault\nSegmentation fault\nSegmentation fault\nchar at 0xbd25e000: 41; final dist 7036 (43654012)\nSegmentation fault\nSegmentation fault\nSegmentation fault\n... \nSegmentation fault\nSegmentation fault\nSegmentation fault\nchar at 0xbd29e000: 41; final dist 5331 (43390163)\nSegmentation fault\nSegmentation fault\nSegmentation fault\n... \n\n In contrast, if FreeBSD\u0027s stack guard-page is disabled, our\n proof-of-concept always survives:\n\n# sysctl security.bsd.stack_guard_page=0\nsecurity.bsd.stack_guard_page: 1 -\u003e 0\n\n% sh -c \u0027while true; do ./FreeBSD_CVE-2017-FGPE; done\u0027\nchar at 0xbe969000: 41; final dist 89894 (19488550)\nchar at 0xbfa6d000: 41; final dist 74525 (1647389)\nchar at 0xbf4df000: 41; final dist 78 (7471182)\nchar at 0xbe9e4000: 41; final dist 112397 (18986765)\nchar at 0xbf693000: 41; final dist 49811 (5685907)\nchar at 0xbf533000: 41; final dist 51037 (7128925)\nchar at 0xbd799000: 41; final dist 26043 (38167995)\nchar at 0xbd54b000: 11; final dist 83754 (40585002)\nchar at 0xbe176000: 41; final dist 36992 (27824256)\nchar at 0xbfa91000: 41; final dist 57449 (1499241)\nchar at 0xbd1b9000: 41; final dist 26115 (44328451)\nchar at 0xbd1c8000: 41; final dist 94852 (44266116)\nchar at 0xbf73a000: 41; final dist 22276 (5003012)\nchar at 0xbe6b1000: 41; final dist 58854 (22341094)\nchar at 0xbeb81000: 41; final dist 124727 (17295159)\nchar at 0xbfb35000: 41; final dist 43174 (829606)\n... \n\n- FreeBSD\u0027s thread library (libthr) mmap()s a secondary PROT_NONE stack\n guard-page at a distance RLIMIT_STACK below the end of the stack:\n\n# sysctl security.bsd.stack_guard_page=1\nsecurity.bsd.stack_guard_page: 0 -\u003e 1\n\n% sh -c \u0027exec procstat -v $$\u0027\n PID START END PRT RES PRES REF SHD FLAG TP PATH\n 2779 0x8048000 0x8050000 r-x 8 8 1 0 CN-- vn /usr/bin/procstat\n... \n 2779 0x28400000 0x28800000 rw- 22 35 2 0 ---- df\n 2779 0xbfbdf000 0xbfbff000 rwx 3 3 1 0 ---D df\n 2779 0xbfbff000 0xbfc00000 r-x 1 1 23 0 ---- ph\n\n% sh -c \u0027LD_PRELOAD=libthr.so exec procstat -v $$\u0027\n PID START END PRT RES PRES REF SHD FLAG TP PATH\n 2798 0x8048000 0x8050000 r-x 8 8 1 0 CN-- vn /usr/bin/procstat\n... \n 2798 0x28400000 0x28800000 rw- 23 35 2 0 ---- df\n 2798 0xbbbfe000 0xbbbff000 --- 0 0 0 0 ---- --\n 2798 0xbfbdf000 0xbfbff000 rwx 3 3 1 0 ---D df\n 2798 0xbfbff000 0xbfc00000 r-x 1 1 23 0 ---- ph\n\n Unfortunately, this secondary stack guard-page does not mitigate the\n vulnerabilities that we discovered in FreeBSD\u0027s stack guard-page\n implementation:\n\n% sysctl security.bsd.stack_guard_page\nsecurity.bsd.stack_guard_page: 1\n\n% sh -c \u0027LD_PRELOAD=libthr.so ./FreeBSD_CVE-2017-FGPU\u0027\nchar at 0xbfbde000: 41\n\n% sh -c \u0027while true; do LD_PRELOAD=libthr.so ./FreeBSD_CVE-2017-FGPE; done\u0027\nSegmentation fault\nSegmentation fault\nSegmentation fault\n... \nSegmentation fault\nSegmentation fault\nSegmentation fault\nchar at 0xbda5e000: 41; final dist 3839 (35262207)\nSegmentation fault\nSegmentation fault\nSegmentation fault\n... \nSegmentation fault\nSegmentation fault\nSegmentation fault\nchar at 0xbdb1e000: 41; final dist 3549 (34475485)\nSegmentation fault\nSegmentation fault\nSegmentation fault\n... \n\n========================================================================\nIV.4.4. Remote exploitation\n========================================================================\n\nBecause FreeBSD\u0027s stack guard-page is disabled by default, we tried (and\nfailed) to remotely exploit a test service vulnerable to:\n\n- an unlimited memory leak that allows us to malloc()ate gigabytes of\n memory;\n\n- a limited recursion that allows us to allocate up to 1MB of stack\n memory. \n\nFreeBSD\u0027s malloc() implementation (jemalloc) mmap()s 4MB chunks of\nanonymous memory that are aligned on multiples of 4MB. The first 4MB\nmmap() chunk starts at 0x28400000, and the last 4MB mmap() chunk ends at\n0xbf800000, because the stack itself already ends at 0xbfc00000; but it\nis impossible to cover this final mmap-stack distance (almost 4MB) with\nthe limited recursion (1MB) of our test service. \nbreak(0x80499b0) = 0 (0x0)\nbreak(0x8400000) = 0 (0x0)\nmmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 672845824 (0x281ad000)\nmmap(0x285ad000,2437120,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 677040128 (0x285ad000)\nmunmap(0x281ad000,2437120) = 0 (0x0)\nmmap(0x0,8388608,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 679477248 (0x28800000)\nmunmap(0x28c00000,4194304) = 0 (0x0)\nmmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 683671552 (0x28c00000)\nmmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 687865856 (0x29000000)\nmmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 692060160 (0x29400000)\nmmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 696254464 (0x29800000)\nmmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 700448768 (0x29c00000)\n... \nmmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = -1103101952 (0xbe400000)\nmmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = -1098907648 (0xbe800000)\nmmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = -1094713344 (0xbec00000)\nmmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = -1090519040 (0xbf000000)\nmmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = -1086324736 (0xbf400000)\nmmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) ERR#12 \u0027Cannot allocate memory\u0027\nbreak(0x8800000) = 0 (0x0)\nmmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) ERR#12 \u0027Cannot allocate memory\u0027\nbreak(0x8c00000) = 0 (0x0)\nmmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) ERR#12 \u0027Cannot allocate memory\u0027\nbreak(0x9000000) = 0 (0x0)\n... \nmmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) ERR#12 \u0027Cannot allocate memory\u0027\nbreak(0x27c00000) = 0 (0x0)\nmmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) ERR#12 \u0027Cannot allocate memory\u0027\nbreak(0x28000000) = 0 (0x0)\nmmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) ERR#12 \u0027Cannot allocate memory\u0027\nbreak(0x28400000) ERR#12 \u0027Cannot allocate memory\u0027\n\n========================================================================\nIV.5. Solaris \u003e= 11.1\n========================================================================\n\n========================================================================\nIV.5.1. Minimal RLIMIT_STACK vulnerability (CVE-2017-3630)\n========================================================================\n\nOn Solaris, ASLR can be enabled or disabled for each ELF binary with the\nSUNW_ASLR dynamic section entry (man elfedit):\n\n$ elfdump /usr/bin/rsh | egrep \u0027ASLR|NX\u0027\n [39] SUNW_ASLR 0x2 ENABLE\n [40] SUNW_NXHEAP 0x2 ENABLE\n [41] SUNW_NXSTACK 0x2 ENABLE\n\nWithout ASLR\n\nIf ASLR is disabled:\n\n- a stack region of size RLIMIT_STACK is reserved in the address-space;\n\n- a 4KB stack guard-page is mapped directly below this stack region;\n\n- the runtime linker ld.so is mapped directly below this stack\n guard-page. \n\n$ cp /usr/bin/sleep . \n$ chmod u+w ./sleep\n$ elfedit -e \u0027dyn:sunw_aslr disable\u0027 ./sleep\n\n$ sh -c \u0027ulimit -S -s; ./sleep 3 \u0026 pmap -r ${!}\u0027\n8192\n7176: ./sleep 3\n... \nFE7B1000 228K r-x---- /lib/ld.so.1\nFE7FA000 8K rwx---- /lib/ld.so.1\nFE7FC000 8K rwx---- /lib/ld.so.1\nFE7FF000 8192K rw----- [ stack ]\n total 17148K\n\n$ sh -c \u0027ulimit -S -s 64; ./sleep 3 \u0026 pmap -r ${!}\u0027\n7244: ./sleep 3\n... \nFEFA1000 228K r-x---- /lib/ld.so.1\nFEFEA000 8K rwx---- /lib/ld.so.1\nFEFEC000 8K rwx---- /lib/ld.so.1\nFEFEF000 64K rw----- [ stack ]\n total 9020K\n\nOn the one hand, a local attacker can exploit this simplified\nstack-clash:\n\n- Step 1 (Clash) is not needed, because ld.so is naturally mapped\n directly below the stack (the distance between the end of ld.so\u0027s\n read-write segment and the start of the stack is 4KB, the stack\n guard-page);\n\n- Step 2 (Run) is not needed, because a local attacker can set\n RLIMIT_STACK to just a few kilobytes, reserve a very small stack\n region, and hence shorten the distance between the stack-pointer and\n the start of the stack (and the end of ld.so\u0027s read-write segment);\n\n- Step 3 (Jump) can be completed with a large stack-based buffer that is\n not fully written to;\n\n- Step 4b (Smash) can be completed by overwriting the function pointers\n in ld.so\u0027s read-write segment with the contents of a stack-based\n buffer. \n\nSuch a simplified stack-clash exploit was first mentioned in Gael\nDelalleau\u0027s 2005 presentation (slide 30). \n\nOn the other hand, a remote attacker cannot modify RLIMIT_STACK and must\ncomplete Step 2 (Run) with a recursive function that consumes the 8MB\n(the default RLIMIT_STACK) between the stack-pointer and the start of\nthe stack. \n\nWith ASLR\n\nIf ASLR is enabled:\n\n- a stack region of size RLIMIT_STACK is reserved in the address-space;\n\n- a 4KB stack guard-page is mapped directly below this stack region;\n\n- the runtime linker ld.so is mapped below this stack guard-page, but at\n a random distance (within a [4KB,128MB] range) -- effectively a large,\n secondary stack guard-page. \n\nOn the one hand, a local attacker can run the simplified \"Without ASLR\"\nstack-clash exploit until the ld.so-stack distance is minimal -- with a\nprobability of 4KB/128MB=1/32K, the distance between the end of ld.so\u0027s\nread-write segment and the start of the stack is exactly 8KB: the stack\nguard-page plus the minimum distance between the stack guard-page and\nld.so (CVE-2017-3629). \n\nOn the other hand, a remote attacker must complete Step 2 (Run) with a\nrecursive function, and:\n\n- has a good chance of exploiting this stack-clash after 32K connections\n (when the ld.so-stack distance is minimal) if the remote service\n re-execve()s (re-randomizes the ld.so-stack distance for each new\n connection);\n\n- cannot exploit this stack-clash if the remote service does not\n re-execve() (does not re-randomize the ld.so-stack distance for each\n new connection) unless the attacker is able to restart the service,\n reboot the server, or target a 32K-server farm. \n\n========================================================================\nIV.5.2. /usr/bin/rsh exploit\n========================================================================\n\n/usr/bin/rsh is SUID-root and its main() function allocates a 50KB\nstack-based buffer that is not written to and can be used to jump over\nthe stack guard-page, into ld.so\u0027s read-write segment, in Step 3 of our\nsimplified stack-clash exploit. \n\nNext, we discovered a general method for gaining eip control in Step 4b:\nsetlocale(LC_ALL, \"\"), called by the main() function of /usr/bin/rsh and\nother SUID binaries, copies the LC_ALL environment variable to several\nstack-based buffers and thus smashes ld.so\u0027s read-write segment and\noverwrites some of ld.so\u0027s function pointers. \n\nLast, we execute our own shell-code: we return-into-binary (/usr/bin/rsh\nis not a PIE), to an instruction that reliably jumps into a copy of our\nLC_ALL environment variable in ld.so\u0027s read-write segment, which is in\nfact read-write-executable. For example, after we gain control of eip:\n\n- on Solaris 11.1, we return to a \"pop; pop; ret\" instruction, because a\n pointer to our shell-code is stored at an 8-byte offset from esp;\n\n- on Solaris 11.3, we return to a \"call *0xc(%ebp)\" instruction, because\n a pointer to our shell-code is stored at a 12-byte offset from ebp. \n\nOur Solaris exploit brute-forces the random ld.so-stack distance and two\nparameters:\n\n- the RLIMIT_STACK;\n\n- the length of the LC_ALL environment variable. \n\n========================================================================\nIV.5.3. Forced-Privilege vulnerability (CVE-2017-3631)\n========================================================================\n\n/usr/bin/rsh is SUID-root, but the shell that we obtained in Step 4b of\nour stack-clash exploit did not grant us full root privileges, only\nnet_privaddr, the privilege to bind to a privileged port number. \nDisappointed by this result, we investigated and found:\n\n$ ggrep -r /usr/bin/rsh /etc 2\u003e/dev/null\n/etc/security/exec_attr.d/core-os:Forced Privilege:solaris:cmd:RO::/usr/bin/rsh:privs=net_privaddr\n\n$ /usr/bin/rsh -h\n/usr/bin/rsh: illegal option -- h\nusage: rsh [ -PN / -PO ] [ -l login ] [ -n ] [ -k realm ] [ -a ] [ -x ] [ -f / -F ] host command\n rsh [ -PN / -PO ] [ -l login ] [ -k realm ] [ -a ] [ -x ] [ -f / -F ] host\n\n# cat truss.out\n... \n7319: execve(\"/usr/bin/rsh\", 0xA9479C548, 0xA94792808) argc = 2\n7319: *** FPRIV: P/E: net_privaddr ***\n... \n\nUnfortunately, this Forced-Privilege protection is based on the pathname\nof SUID-root binaries, which can be execve()d through hard-links, under\ndifferent pathnames (CVE-2017-3631). For example, we discovered that\nreadable SUID-root binaries can be execve()d through hard-links in\n/proc:\n\n$ sleep 3 \u003c /usr/bin/rsh \u0026 /proc/${!}/fd/0 -h\n[1] 7333\n/proc/7333/fd/0: illegal option -- h\nusage: rsh [ -PN / -PO ] [ -l login ] [ -n ] [ -k realm ] [ -a ] [ -x ] [ -f / -F ] host command\n rsh [ -PN / -PO ] [ -l login ] [ -k realm ] [ -a ] [ -x ] [ -f / -F ] host\n\n# cat truss.out\n... \n7335: execve(\"/proc/7333/fd/0\", 0xA947CA508, 0xA94792808) argc = 2\n7335: *** SUID: ruid/euid/suid = 100 / 0 / 0 ***\n... \n\nThis vulnerability allows us to bypass the Forced-Privilege protection\nand obtain full root privileges with our /usr/bin/rsh exploit. \n\n\n========================================================================\nV. Acknowledgments\n========================================================================\n\nWe thank the members of the distros list, Oracle/Solaris, Exim, Sudo,\nsecurity@kernel.org, grsecurity/PaX, and OpenBSD. SEC Consult Vulnerability Lab Security Advisory \u003c 20190904-0 \u003e\n=======================================================================\n title: Multiple vulnerabilities\n product: Cisco RV340, Cisco RV340W, Cisco RV345, Cisco RV345P,\n Cisco RV260, Cisco RV260P, Cisco RV260W, Cisco 160,\n Cisco 160W\n vulnerable version: Cisco RV34X - 1.0.02.16, Cisco RV16X/26X - 1.0.00.15\n fixed version: see \"Solution\"\n CVE number: -\n impact: High\n homepage: https://www.cisco.com/\n found: 2019-05-15\n by: T. Weber, S. Viehb\u00f6ck (Office Vienna)\n IoT Inspector\n SEC Consult Vulnerability Lab\n\n An integrated part of SEC Consult\n Europe | Asia | North America\n\n https://www.sec-consult.com\n\n=======================================================================\n\nVendor description:\n-------------------\n\"Securely connecting your small business to the outside world is as important\nas connecting your internal network devices to one another. Cisco Small\nBusiness RV Series Routers offer virtual private networking (VPN) technology\nso your remote workers can connect to your network through a secure Internet\npathway.\"\n\nSource: https://www.cisco.com/c/en/us/products/routers/small-business-rv-series-routers/index.html\n\n\nBusiness recommendation:\n------------------------\nWe want to thank Cisco for the very quick and professional response and great\ncoordination. Customers are urged to update the firmware of their devices. \n\n\nVulnerability overview/description:\n-----------------------------------\n1) Hardcoded Credentials\nThe device contains hardcoded users and passwords which can be used to login\nvia SSH on an emulated device at least. \n\nDuring the communication with Cisco it turned out that:\n\"Accounts like the \u0027debug-admin\u0027 and \u0027root\u0027 can not be accessed\nfrom console port, CLI or webui\". \nTherefore, these accounts had no real functionality and cannot be used for\nmalicious actions. \n\n2) Known GNU glibc Vulnerabilities\nThe used GNU glibc in version 2.19 is outdated and contains multiple known\nvulnerabilities. The outdated version was found by IoT Inspector. One of\nthe discovered vulnerabilities (CVE-2015-7547, \"getaddrinfo() buffer overflow\")\nwas verified by using the MEDUSA scalable firmware runtime. \n\n3) Known BusyBox Vulnerabilities\nThe used BusyBox toolkit in version 1.23.2 is outdated and contains multiple\nknown vulnerabilities. The outdated version was found by IoT Inspector. \nOne of the discovered vulnerabilities (CVE-2017-16544) was verified by using\nthe MEDUSA scaleable firmware runtime. \n\n\n4) Multiple Vulnerabilities - IoT Inspector Report\nFurther information can be found in IoT Inspector report:\nhttps://r.sec-consult.com/ciscoiot\n\n\nProof of concept:\n-----------------\n1) Hardcoded Credentials\nThe following hardcoded hashes were found in the \u0027shadow\u0027 file of the firmware:\nroot:$1$hPNSjUZA$7eKqEpqVYltt9xJ6f0OGf0:15533:0:99999:7:::\ndebug-admin:$1$.AAm0iJ4$na9wZwly9pSrdS8MhcGKw/:15541:0:99999:7:::\n[...]\n\nThe undocumented user \u0027debug-admin\u0027 is also contained in this file. \n\nStarting the dropbear daemon as background process on emulated firmware:\n-------------------------------------------------------------------------------\n# dropbear -E\n# [1109] \u003ctimestamp\u003e Running in background\n#\n# [1112] \u003ctimestamp\u003e Child connection from \u003cIP\u003e:52718\n[1112] \u003ctimestamp\u003e /var must be owned by user or root, and not writable by others\n[1112] \u003ctimestamp\u003e Password auth succeeded for \u0027debug-admin\u0027 from \u003cIP\u003e:52718\n-------------------------------------------------------------------------------\n\nLog on via another host connected to the same network. For this PoC the\npassword of the debug-admin was changed in the \u0027shadow\u0027 file. \n-------------------------------------------------------------------------------\n[root@localhost medusa]# ssh debug-admin@\u003cIP\u003e /bin/ash -i\ndebug-admin@\u003cIP\u003e\u0027s password:\n/bin/ash: can\u0027t access tty; job control turned off\n\n\nBusyBox v1.23.2 (2018-11-21 18:22:56 IST) built-in shell (ash)\n\n/tmp $\n-------------------------------------------------------------------------------\n\nThe \u0027debug-admin\u0027 user has the same privileges like \u0027root\u0027. This can be\ndetermined from the corresponding sudoers file in the firmware:\n[...]\n## User privilege specification\n##\nroot ALL=(ALL) ALL\ndebug-admin ALL=(ALL) ALL\n\n## Uncomment to allow members of group wheel to execute any command\n# %wheel ALL=(ALL) ALL\n[...]\n\nDuring the communication with Cisco it turned out that:\n\"Accounts like the \u0027debug-admin\u0027 and \u0027root\u0027 can not be accessed\nfrom console port, CLI or webui\". \nTherefore, these accounts had no real functionality and cannot be used for\nmalicious actions. \n\n2) Known GNU glibc Vulnerabilities\nGNU glibc version 2.19 contains multiple CVEs like:\nCVE-2014-4043, CVE-2014-9402, CVE-2014-9761, CVE-2014-9984, CVE-2015-1472,\nCVE-2015-5277, CVE-2015-8778, CVE-2015-8779, CVE-2017-1000366 and more. \n\nThe getaddrinfo() buffer overflow vulnerability was checked with the help of\nthe exploit code from https://github.com/fjserna/CVE-2015-7547. It was compiled\nand executed on the emulated device to test the system. \n\n# python cve-2015-7547-poc.py \u0026\n[1] 961\n# chroot /medusa_rootfs/ bin/ash\n\n\nBusyBox v1.23.2 (2018-11-21 18:22:56 IST) built-in shell (ash)\n\n# gdb cve-2015-7547_glibc_getaddrinfo\n[...]\n[UDP] Total Data len recv 36\n[UDP] Total Data len recv 36\nConnected with 127.0.0.1:41782\n[TCP] Total Data len recv 76\n[TCP] Request1 len recv 36\n[TCP] Request2 len recv 36\nCannot access memory at address 0x4\n\nProgram received signal SIGSEGV, Segmentation fault. \n0x76f1fd58 in ?? () from /lib/libc.so.6\n(gdb)\n\nReferences:\nhttps://security.googleblog.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html\nhttps://github.com/fjserna/CVE-2015-7547\n\n\n3) Known BusyBox Vulnerabilities\nBusyBox version 1.23.2 contains multiple CVEs like:\nCVE-2016-2148, CVE-2016-6301, CVE-2015-9261, CVE-2016-2147, CVE-2018-20679,\nCVE-2017-16544 and CVE-2019-5747. \nThe BusyBox shell autocompletion vulnerability (CVE-2017-16544) was verified on\nan emulated device:\n\nA file with the name \"\\ectest\\n\\e]55;test.txt\\a\" was created to trigger the\nvulnerability. \n-------------------------------------------------------------------------------\n# ls \"pressing \u003cTAB\u003e\"\ntest\n]55;test.txt\n#\n-------------------------------------------------------------------------------\n\n4) Multiple Vulnerabilities - IoT Inspector Report\nFurther information can be found in IoT Inspector report:\nhttps://r.sec-consult.com/ciscoiot\n\nThe summary is below:\nIoT Inspector Vulnerability #1 BusyBox CVE entries\nOutdated BusyBox version is affected by 7 published CVEs. \n\nIoT Inspector Vulnerability #2 curl CVE entries\nOutdated curl version is affected by 35 published CVEs. \n\nIoT Inspector Vulnerability #3 GNU glibc CVE entries\nOutdated GNU glibc version is affected by 44 published CVEs. \n\nIoT Inspector Vulnerability #4 GNU glibc getaddrinfo() buffer overflow\nOutdated GNU glibc version is affected by CVE-2015-7547. \n\nIoT Inspector Vulnerability #5 Hardcoded password hashes\nFirmware contains multiple hardcoded credentials. \n\nIoT Inspector Vulnerability #6 Linux Kernel CVE entries\nOutdated Linux Kernel version affected by 512 published CVEs. \n\nIoT Inspector Vulnerability #7 MiniUPnPd CVE entries\nOutdated MiniUPnPd version affected by 2 published CVEs. \n\nIoT Inspector Vulnerability #8 Dnsmasq CVE entries\nOutdated MiniUPnPd version affected by 1 published CVE. \n\nIoT Inspector Vulnerability #9 Linux Kernel Privilege Escalation \u201cpp_key\u201d\nOutdated Linux Kernel version is affected by CVE-2015-7547. \n\nIoT Inspector Vulnerability #10 OpenSSL CVE entries\nOutdated OpenSSL version affected by 6 published CVEs. \n\n\nVulnerable / tested versions:\n-----------------------------\nThe following firmware versions have been tested with IoT Inspector and\nfirmware emulation techniques:\nCisco RV340 / 1.0.02.16\nCisco RV340W / 1.0.02.16\nCisco RV345 / 1.0.02.16\nCisco RV345P / 1.0.02.16\nThe following firmware versions have been tested with IoT Inspector only:\nCisco RV260 / 1.0.00.15\nCisco RV260P / 1.0.00.15\nCisco RV260W / 1.0.00.15\nCisco RV160 / 1.0.00.15\nCisco RV160P / 1.0.00.15\n\nThe firmware was obtained from the vendor website:\nhttps://software.cisco.com/download/home/286287791/type/282465789/release/1.0.02.16\nhttps://software.cisco.com/download/home/286316464/type/282465789/release/1.0.00.15\n\n\nVendor contact timeline:\n------------------------\n2019-05-15: Contacting vendor through psirt@cisco.com. \n2019-05-16: Vendor confirmed the receipt. \n2019-05-2019-08: Periodic updates about the investigation from the vendor. \n Clarification which of the reported issues will be fixed. \n2019-08-20: The vendor proposed the next possible publication date for the\n advisory for 2019-09-04. The vendor added the RV160 and RV260\n router series to be vulnerable to the same issues too. \n2019-09-04: Coordinated advisory release. \n\n\nSolution:\n---------\nUpgrade to the newest available firmware version. \n\nAdditionally, the vendor provides the following security notice:\nhttps://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190904-sb-vpnrouter\n\n\nWorkaround:\n-----------\nNone. \n\n\nAdvisory URL:\n-------------\nhttps://www.sec-consult.com/en/vulnerability-lab/advisories/index.html\n\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSEC Consult Vulnerability Lab\n\nSEC Consult\nEurope | Asia | North America\n\nAbout SEC Consult Vulnerability Lab\nThe SEC Consult Vulnerability Lab is an integrated part of SEC Consult. It\nensures the continued knowledge gain of SEC Consult in the field of network\nand application security to stay ahead of the attacker. The SEC Consult\nVulnerability Lab supports high-quality penetration testing and the evaluation\nof new offensive and defensive technologies for our customers. Hence our\ncustomers obtain the most current information about vulnerabilities and valid\nrecommendation about the risk profile of new technologies. \n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nInterested to work with the experts of SEC Consult?\nSend us your application https://www.sec-consult.com/en/career/index.html\n\nInterested in improving your cyber security with the experts of SEC Consult?\nContact our local offices https://www.sec-consult.com/en/contact/index.html\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nMail: research at sec-consult dot com\nWeb: https://www.sec-consult.com\nBlog: http://blog.sec-consult.com\nTwitter: https://twitter.com/sec_consult\n\nEOF T. Weber / @2019\n\n", "sources": [ { "db": "NVD", "id": "CVE-2017-1000366" }, { "db": "JVNDB", "id": "JVNDB-2017-005209" }, { "db": "VULHUB", "id": "VHN-100094" }, { "db": "VULMON", "id": "CVE-2017-1000366" }, { "db": "PACKETSTORM", "id": "142999" }, { "db": "PACKETSTORM", "id": "143001" }, { "db": "PACKETSTORM", "id": "142992" }, { "db": "PACKETSTORM", "id": "143033" }, { "db": "PACKETSTORM", "id": "143016" }, { "db": "PACKETSTORM", "id": "154361" }, { "db": "PACKETSTORM", "id": "143005" } ], "trust": 2.43 }, "exploit_availability": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/exploit_availability#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "reference": "https://vulmon.com/exploitdetails?qidtp=exploitdb\u0026qid=42276", "trust": 0.3, "type": "exploit" }, { "reference": "https://www.scap.org.cn/vuln/vhn-100094", "trust": 0.1, "type": "unknown" } ], "sources": [ { "db": "VULHUB", "id": "VHN-100094" }, { "db": "VULMON", "id": "CVE-2017-1000366" } ] }, "external_ids": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/external_ids#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "db": "NVD", "id": "CVE-2017-1000366", "trust": 3.3 }, { "db": "PACKETSTORM", "id": "154361", "trust": 1.9 }, { "db": "BID", "id": "99127", "trust": 1.8 }, { "db": "EXPLOIT-DB", "id": "42274", "trust": 1.8 }, { "db": "EXPLOIT-DB", "id": "42276", "trust": 1.8 }, { "db": "EXPLOIT-DB", "id": "42275", "trust": 1.8 }, { "db": "SECTRACK", "id": "1038712", "trust": 1.8 }, { "db": "MCAFEE", "id": "SB10205", "trust": 1.8 }, { "db": "JVNDB", "id": "JVNDB-2017-005209", "trust": 0.8 }, { "db": "CNNVD", "id": "CNNVD-201706-808", "trust": 0.7 }, { "db": "AUSCERT", "id": "ESB-2019.3313", "trust": 0.6 }, { "db": "PACKETSTORM", "id": "143001", "trust": 0.2 }, { "db": "PACKETSTORM", "id": "142992", "trust": 0.2 }, { "db": "PACKETSTORM", "id": "142999", "trust": 0.2 }, { "db": "PACKETSTORM", "id": "143005", "trust": 0.2 }, { "db": "PACKETSTORM", "id": "142990", "trust": 0.1 }, { "db": "PACKETSTORM", "id": "143205", "trust": 0.1 }, { "db": "PACKETSTORM", "id": "143207", "trust": 0.1 }, { "db": "PACKETSTORM", "id": "143196", "trust": 0.1 }, { "db": "PACKETSTORM", "id": "143201", "trust": 0.1 }, { "db": "PACKETSTORM", "id": "143225", "trust": 0.1 }, { "db": "VULHUB", "id": "VHN-100094", "trust": 0.1 }, { "db": "VULMON", "id": "CVE-2017-1000366", "trust": 0.1 }, { "db": "PACKETSTORM", "id": "143033", "trust": 0.1 }, { "db": "PACKETSTORM", "id": "143016", "trust": 0.1 } ], "sources": [ { "db": "VULHUB", "id": "VHN-100094" }, { "db": "VULMON", "id": "CVE-2017-1000366" }, { "db": "JVNDB", "id": "JVNDB-2017-005209" }, { "db": "PACKETSTORM", "id": "142999" }, { "db": "PACKETSTORM", "id": "143001" }, { "db": "PACKETSTORM", "id": "142992" }, { "db": "PACKETSTORM", "id": "143033" }, { "db": "PACKETSTORM", "id": "143016" }, { "db": "PACKETSTORM", "id": "154361" }, { "db": "PACKETSTORM", "id": "143005" }, { "db": "CNNVD", "id": "CNNVD-201706-808" }, { "db": "NVD", "id": "CVE-2017-1000366" } ] }, "id": "VAR-201706-0334", "iot": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/iot#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": true, "sources": [ { "db": "VULHUB", "id": "VHN-100094" } ], "trust": 0.01 }, "last_update_date": "2024-09-19T19:56:12.888000Z", "patch": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/patch#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "title": "CVE-2017-1000366", "trust": 0.8, "url": "https://access.redhat.com/security/cve/CVE-2017-1000366" }, { "title": "CVE-2017-1000366", "trust": 0.8, "url": "https://www.suse.com/security/cve/CVE-2017-1000366/" }, { "title": "SUSE products and a new security bug class referred to as \"Stack Clash\".", "trust": 0.8, "url": "https://www.suse.com/support/kb/doc/?id=7020973" }, { "title": "glibc Security vulnerabilities", "trust": 0.6, "url": "http://www.cnnvd.org.cn/web/xxk/bdxqById.tag?id=71084" }, { "title": "Red Hat: Important: glibc security update", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=red_hat_security_advisories\u0026qid=RHSA-20171480 - Security Advisory" }, { "title": "Red Hat: Important: glibc security update", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=red_hat_security_advisories\u0026qid=RHSA-20171481 - Security Advisory" }, { "title": "Red Hat: Important: glibc security update", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=red_hat_security_advisories\u0026qid=RHSA-20171479 - Security Advisory" }, { "title": "Red Hat: Important: Red Hat Container Development Kit 3.0.0 security update", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=red_hat_security_advisories\u0026qid=RHSA-20171567 - Security Advisory" }, { "title": "Ubuntu Security Notice: eglibc, glibc vulnerability", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=ubuntu_security_notice\u0026qid=USN-3323-1" }, { "title": "Ubuntu Security Notice: eglibc vulnerability", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=ubuntu_security_notice\u0026qid=USN-3323-2" }, { "title": "Debian Security Advisories: DSA-3887-1 glibc -- security update", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=debian_security_advisories\u0026qid=09de7cf27f70b4503f183a914f8b80ac" }, { "title": "Red Hat: Important: Red Hat 3scale API Management Platform 2.0.0 security update", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=red_hat_security_advisories\u0026qid=RHSA-20171712 - Security Advisory" }, { "title": "Amazon Linux AMI: ALAS-2017-844", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=amazon_linux_ami\u0026qid=ALAS-2017-844" }, { "title": "Arch Linux Advisories: [ASA-201706-22] lib32-glibc: privilege escalation", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=arch_linux_advisories\u0026qid=ASA-201706-22" }, { "title": "Arch Linux Advisories: [ASA-201706-23] glibc: privilege escalation", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=arch_linux_advisories\u0026qid=ASA-201706-23" }, { "title": "Red Hat: CVE-2017-1000366", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=red_hat_cve_database\u0026qid=CVE-2017-1000366" }, { "title": "Arch Linux Issues: ", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=arch_linux_issues\u0026qid=CVE-2017-1000366" }, { "title": "Red Hat: Moderate: glibc security, bug fix, and enhancement update", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=red_hat_security_advisories\u0026qid=RHSA-20180805 - Security Advisory" }, { "title": "Brocade Security Advisories: BSA-2017-355", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=brocade_security_advisories\u0026qid=ceec973689010b3f9fce9a7f3e1542a1" }, { "title": "Oracle VM Server for x86 Bulletins: Oracle VM Server for x86 Bulletin - July 2017", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=oracle_vm_server_for_x86_bulletins\u0026qid=f1373f5dee274fec5bdcbc4c7e701395" }, { "title": "IBM: IBM Security Bulletin: Vyatta 5600 vRouter Software Patches \u2013 Release 1801-za", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=ibm_psirt_blog\u0026qid=8710e4e233940f7482a6adad4643a7a8" }, { "title": "Oracle Linux Bulletins: Oracle Linux Bulletin - July 2017", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=oracle_linux_bulletins\u0026qid=549dc795290b298746065b62b4bb7928" }, { "title": "ansible-everyday", "trust": 0.1, "url": "https://github.com/kaosagnt/ansible-everyday " }, { "title": "Exp101tsArchiv30thers", "trust": 0.1, "url": "https://github.com/nu11secur1ty/Exp101tsArchiv30thers " }, { "title": "awesome-cve-poc_qazbnm456", "trust": 0.1, "url": "https://github.com/xbl3/awesome-cve-poc_qazbnm456 " } ], "sources": [ { "db": "VULMON", "id": "CVE-2017-1000366" }, { "db": "JVNDB", "id": "JVNDB-2017-005209" }, { "db": "CNNVD", "id": "CNNVD-201706-808" } ] }, "problemtype_data": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/problemtype_data#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "problemtype": "CWE-119", "trust": 1.9 } ], "sources": [ { "db": "VULHUB", "id": "VHN-100094" }, { "db": "JVNDB", "id": "JVNDB-2017-005209" }, { "db": "NVD", "id": "CVE-2017-1000366" } ] }, "references": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/references#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "trust": 2.4, "url": "http://www.securityfocus.com/bid/99127" }, { "trust": 2.4, "url": "http://www.debian.org/security/2017/dsa-3887" }, { "trust": 2.4, "url": "http://packetstormsecurity.com/files/154361/cisco-device-hardcoded-credentials-gnu-glibc-busybox.html" }, { "trust": 2.1, "url": "https://access.redhat.com/security/cve/cve-2017-1000366" }, { "trust": 2.0, "url": "https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt" }, { "trust": 2.0, "url": "https://access.redhat.com/errata/rhsa-2017:1480" }, { "trust": 1.9, "url": "https://www.exploit-db.com/exploits/42276/" }, { "trust": 1.9, "url": "https://security.gentoo.org/glsa/201706-19" }, { "trust": 1.9, "url": "https://access.redhat.com/errata/rhsa-2017:1479" }, { "trust": 1.9, "url": "https://access.redhat.com/errata/rhsa-2017:1481" }, { "trust": 1.8, "url": "https://seclists.org/bugtraq/2019/sep/7" }, { "trust": 1.8, "url": "https://www.suse.com/security/cve/cve-2017-1000366/" }, { "trust": 1.8, "url": "https://www.suse.com/support/kb/doc/?id=7020973" }, { "trust": 1.8, "url": "https://www.exploit-db.com/exploits/42274/" }, { "trust": 1.8, "url": "https://www.exploit-db.com/exploits/42275/" }, { "trust": 1.8, "url": "http://seclists.org/fulldisclosure/2019/sep/7" }, { "trust": 1.8, "url": "https://access.redhat.com/errata/rhsa-2017:1567" }, { "trust": 1.8, "url": "https://access.redhat.com/errata/rhsa-2017:1712" }, { "trust": 1.8, "url": "http://www.securitytracker.com/id/1038712" }, { "trust": 1.7, "url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=sb10205" }, { "trust": 1.5, "url": "https://nvd.nist.gov/vuln/detail/cve-2017-1000366" }, { "trust": 0.8, "url": "http://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2017-1000366" }, { "trust": 0.6, "url": "https://www.ibm.com/support/docview.wss?uid=ibm10960426" }, { "trust": 0.6, "url": "https://www.ibm.com/support/docview.wss?uid=ibm10887793" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2019.3313/" }, { "trust": 0.6, "url": "https://www-01.ibm.com/support/docview.wss?uid=ibm10960426" }, { "trust": 0.3, "url": "https://www.redhat.com/mailman/listinfo/rhsa-announce" }, { "trust": 0.3, "url": "https://access.redhat.com/security/vulnerabilities/stackguard" }, { "trust": 0.3, "url": "https://bugzilla.redhat.com/):" }, { "trust": 0.3, "url": "https://access.redhat.com/security/team/key/" }, { "trust": 0.3, "url": "https://access.redhat.com/articles/11258" }, { "trust": 0.3, "url": "https://access.redhat.com/security/team/contact/" }, { "trust": 0.3, "url": "https://access.redhat.com/security/updates/classification/#important" }, { "trust": 0.1, "url": "https://kc.mcafee.com/corporate/index?page=content\u0026amp;id=sb10205" }, { "trust": 0.1, "url": "https://cwe.mitre.org/data/definitions/119.html" }, { "trust": 0.1, "url": "https://usn.ubuntu.com/3323-1/" }, { "trust": 0.1, "url": "https://nvd.nist.gov" }, { "trust": 0.1, "url": "https://tools.cisco.com/security/center/viewalert.x?alertid=54249" }, { "trust": 0.1, "url": "https://www.debian.org/security/" }, { "trust": 0.1, "url": "https://www.debian.org/security/faq" }, { "trust": 0.1, "url": "http://creativecommons.org/licenses/by-sa/2.5" }, { "trust": 0.1, "url": "http://nvd.nist.gov/nvd.cfm?cvename=cve-2016-6323" }, { "trust": 0.1, "url": "http://nvd.nist.gov/nvd.cfm?cvename=cve-2015-5180" }, { "trust": 0.1, "url": "http://nvd.nist.gov/nvd.cfm?cvename=cve-2017-1000366" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2016-6323" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2015-5180" }, { "trust": 0.1, "url": "https://security.gentoo.org/" }, { "trust": 0.1, "url": "https://bugs.gentoo.org." }, { "trust": 0.1, "url": "https://googleprojectzero.blogspot.com/2016/06/exploiting-recursion-in-linux-kernel_20.html" }, { "trust": 0.1, "url": "https://grsecurity.net/" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2017-1000370" }, { "trust": 0.1, "url": "http://cansecwest.com/core05/memory_vulns_delalleau.pdf" }, { "trust": 0.1, "url": "https://cybersecurity.upv.es/attacks/offset2lib/offset2lib.html" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2017-1000373" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2017-1000371" }, { "trust": 0.1, "url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d1fd836dcf00d2028c700c7e44d2c23404062c90" }, { "trust": 0.1, "url": "https://en.wikipedia.org/wiki/irwin-hall_distribution)," }, { "trust": 0.1, "url": "https://grsecurity.net/features.php);" }, { "trust": 0.1, "url": "https://bugzilla.redhat.com/show_bug.cgi?id=cve-2010-2240" }, { "trust": 0.1, "url": "https://jon.oberheide.org/files/infiltrate12-thestackisback.pdf" }, { "trust": 0.1, "url": "http://phrack.org/issues/63/14.html" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2010-2240" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2017-1000365" }, { "trust": 0.1, "url": "http://www.gnu.org/software/cflow/);" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2017-1000376" }, { "trust": 0.1, "url": "http://blog.exodusintel.com/2013/01/07/who-was-phone/" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2016-3672" }, { "trust": 0.1, "url": "https://jon.oberheide.org/blog/2010/11/29/exploiting-stack-overflows-in-the-linux-kernel/" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2017-1000369" }, { "trust": 0.1, "url": "http://www.invisiblethingslab.com/resources/misc-2010/xorg-large-memory-attacks.pdf" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2017-1083" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2017-1000372" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2017-1082" }, { "trust": 0.1, "url": "https://github.com/fjserna/cve-2015-7547" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2016-6301" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2015-1472" }, { "trust": 0.1, "url": "https://www.cisco.com/c/en/us/products/routers/small-business-rv-series-routers/index.html" }, { "trust": 0.1, "url": "https://r.sec-consult.com/ciscoiot" }, { "trust": 0.1, "url": "https://security.googleblog.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html" }, { "trust": 0.1, "url": "https://github.com/fjserna/cve-2015-7547." }, { "trust": 0.1, "url": "https://www.sec-consult.com/en/career/index.html" }, { "trust": 0.1, "url": "https://www.cisco.com/" }, { "trust": 0.1, "url": "https://www.sec-consult.com" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2014-9402" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2015-5277" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2015-8778" }, { "trust": 0.1, "url": "https://twitter.com/sec_consult" }, { "trust": 0.1, "url": "https://tools.cisco.com/security/center/content/ciscosecurityadvisory/cisco-sa-20190904-sb-vpnrouter" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2015-8779" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2015-9261" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2015-7547" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2016-2147" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2014-9984" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2014-9761" }, { "trust": 0.1, "url": "http://blog.sec-consult.com" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2014-4043" }, { "trust": 0.1, "url": "https://www.sec-consult.com/en/vulnerability-lab/advisories/index.html" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2017-16544" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2016-2148" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2018-20679" }, { "trust": 0.1, "url": "https://software.cisco.com/download/home/286316464/type/282465789/release/1.0.00.15" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-5747" }, { "trust": 0.1, "url": "https://www.sec-consult.com/en/contact/index.html" }, { "trust": 0.1, "url": "https://software.cisco.com/download/home/286287791/type/282465789/release/1.0.02.16" } ], "sources": [ { "db": "VULHUB", "id": "VHN-100094" }, { "db": "VULMON", "id": "CVE-2017-1000366" }, { "db": "JVNDB", "id": "JVNDB-2017-005209" }, { "db": "PACKETSTORM", "id": "142999" }, { "db": "PACKETSTORM", "id": "143001" }, { "db": "PACKETSTORM", "id": "142992" }, { "db": "PACKETSTORM", "id": "143033" }, { "db": "PACKETSTORM", "id": "143016" }, { "db": "PACKETSTORM", "id": "154361" }, { "db": "PACKETSTORM", "id": "143005" }, { "db": "CNNVD", "id": "CNNVD-201706-808" }, { "db": "NVD", "id": "CVE-2017-1000366" } ] }, "sources": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#", "data": { "@container": "@list" } }, "data": [ { "db": "VULHUB", "id": "VHN-100094" }, { "db": "VULMON", "id": "CVE-2017-1000366" }, { "db": "JVNDB", "id": "JVNDB-2017-005209" }, { "db": "PACKETSTORM", "id": "142999" }, { "db": "PACKETSTORM", "id": "143001" }, { "db": "PACKETSTORM", "id": "142992" }, { "db": "PACKETSTORM", "id": "143033" }, { "db": "PACKETSTORM", "id": "143016" }, { "db": "PACKETSTORM", "id": "154361" }, { "db": "PACKETSTORM", "id": "143005" }, { "db": "CNNVD", "id": "CNNVD-201706-808" }, { "db": "NVD", "id": "CVE-2017-1000366" } ] }, "sources_release_date": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources_release_date#", "data": { "@container": "@list" } }, "data": [ { "date": "2017-06-19T00:00:00", "db": "VULHUB", "id": "VHN-100094" }, { "date": "2017-06-19T00:00:00", "db": "VULMON", "id": "CVE-2017-1000366" }, { "date": "2017-07-21T00:00:00", "db": "JVNDB", "id": "JVNDB-2017-005209" }, { "date": "2017-06-19T23:54:30", "db": "PACKETSTORM", "id": "142999" }, { "date": "2017-06-19T23:54:48", "db": "PACKETSTORM", "id": "143001" }, { "date": "2017-06-19T23:53:10", "db": "PACKETSTORM", "id": "142992" }, { "date": "2017-06-20T22:26:23", "db": "PACKETSTORM", "id": "143033" }, { "date": "2017-06-20T00:36:06", "db": "PACKETSTORM", "id": "143016" }, { "date": "2019-09-04T18:32:22", "db": "PACKETSTORM", "id": "154361" }, { "date": "2017-06-19T23:55:23", "db": "PACKETSTORM", "id": "143005" }, { "date": "2017-06-20T00:00:00", "db": "CNNVD", "id": "CNNVD-201706-808" }, { "date": "2017-06-19T16:29:00.310000", "db": "NVD", "id": "CVE-2017-1000366" } ] }, "sources_update_date": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources_update_date#", "data": { "@container": "@list" } }, "data": [ { "date": "2020-10-15T00:00:00", "db": "VULHUB", "id": "VHN-100094" }, { "date": "2020-10-15T00:00:00", "db": "VULMON", "id": "CVE-2017-1000366" }, { "date": "2017-07-21T00:00:00", "db": "JVNDB", "id": "JVNDB-2017-005209" }, { "date": "2019-09-06T00:00:00", "db": "CNNVD", "id": "CNNVD-201706-808" }, { "date": "2020-10-15T13:28:10.487000", "db": "NVD", "id": "CVE-2017-1000366" } ] }, "threat_type": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/threat_type#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "local", "sources": [ { "db": "PACKETSTORM", "id": "142992" }, { "db": "CNNVD", "id": "CNNVD-201706-808" } ], "trust": 0.7 }, "title": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/title#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "glibc Buffer error vulnerability", "sources": [ { "db": "JVNDB", "id": "JVNDB-2017-005209" } ], "trust": 0.8 }, "type": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/type#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "buffer error", "sources": [ { "db": "CNNVD", "id": "CNNVD-201706-808" } ], "trust": 0.6 } }
var-202105-1306
Vulnerability from variot
The mq_notify function in the GNU C Library (aka glibc) versions 2.32 and 2.33 has a use-after-free. It may use the notification thread attributes object (passed through its struct sigevent parameter) after it has been freed by the caller, leading to a denial of service (application crash) or possibly unspecified other impact. GNU C Library ( alias glibc) Is vulnerable to the use of freed memory.Information is obtained, information is tampered with, and service is disrupted (DoS) It may be put into a state. The vulnerability stems from the library's mq_notify function having a use-after-free feature. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 202107-07
https://security.gentoo.org/
Severity: Normal Title: glibc: Multiple vulnerabilities Date: July 06, 2021 Bugs: #764176, #767718, #772425, #792261 ID: 202107-07
Synopsis
Multiple vulnerabilities in glibc could result in Denial of Service.
Affected packages
-------------------------------------------------------------------
Package / Vulnerable / Unaffected
-------------------------------------------------------------------
1 sys-libs/glibc < 2.33-r1 >= 2.33-r1
Description
Multiple vulnerabilities have been discovered in glibc. Please review the CVE identifiers referenced below for details.
Impact
An attacker could cause a possible Denial of Service condition.
Workaround
There is no known workaround at this time.
Resolution
All glibc users should upgrade to the latest version:
# emerge --sync # emerge --ask --oneshot --verbose ">=sys-libs/glibc-2.33-r1"
References
[ 1 ] CVE-2019-25013 https://nvd.nist.gov/vuln/detail/CVE-2019-25013 [ 2 ] CVE-2020-27618 https://nvd.nist.gov/vuln/detail/CVE-2020-27618 [ 3 ] CVE-2021-27645 https://nvd.nist.gov/vuln/detail/CVE-2021-27645 [ 4 ] CVE-2021-3326 https://nvd.nist.gov/vuln/detail/CVE-2021-3326 [ 5 ] CVE-2021-33574 https://nvd.nist.gov/vuln/detail/CVE-2021-33574
Availability
This GLSA and any updates to it are available for viewing at the Gentoo Security Website:
https://security.gentoo.org/glsa/202107-07
Concerns?
Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users' machines is of utmost importance to us. Any security concerns should be addressed to security@gentoo.org or alternatively, you may file a bug at https://bugs.gentoo.org.
License
Copyright 2021 Gentoo Foundation, Inc; referenced text belongs to its owner(s).
The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license.
https://creativecommons.org/licenses/by-sa/2.5
. Bugs fixed (https://bugzilla.redhat.com/):
1944888 - CVE-2021-21409 netty: Request smuggling via content-length header 2004133 - CVE-2021-37136 netty-codec: Bzip2Decoder doesn't allow setting size restrictions for decompressed data 2004135 - CVE-2021-37137 netty-codec: SnappyFrameDecoder doesn't restrict chunk length and may buffer skippable chunks in an unnecessary way 2030932 - CVE-2021-44228 log4j-core: Remote code execution in Log4j 2.x when logs contain an attacker-controlled string value
- JIRA issues fixed (https://issues.jboss.org/):
LOG-1971 - Applying cluster state is causing elasticsearch to hit an issue and become unusable
- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
====================================================================
Red Hat Security Advisory
Synopsis: Moderate: glibc security, bug fix, and enhancement update Advisory ID: RHSA-2021:4358-01 Product: Red Hat Enterprise Linux Advisory URL: https://access.redhat.com/errata/RHSA-2021:4358 Issue date: 2021-11-09 CVE Names: CVE-2021-27645 CVE-2021-33574 CVE-2021-35942 ==================================================================== 1. Summary:
An update for glibc is now available for Red Hat Enterprise Linux 8.
Red Hat Product Security has rated this update as having a security impact of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.
- Relevant releases/architectures:
Red Hat Enterprise Linux AppStream (v. 8) - aarch64, ppc64le, s390x, x86_64 Red Hat Enterprise Linux BaseOS (v. 8) - aarch64, ppc64le, s390x, x86_64 Red Hat Enterprise Linux CRB (v. 8) - aarch64, ppc64le, s390x, x86_64
- Description:
The glibc packages provide the standard C libraries (libc), POSIX thread libraries (libpthread), standard math libraries (libm), and the name service cache daemon (nscd) used by multiple programs on the system. Without these libraries, the Linux system cannot function correctly.
Security Fix(es):
-
glibc: Arbitrary read in wordexp() (CVE-2021-35942)
-
glibc: Use-after-free in addgetnetgrentX function in netgroupcache.c (CVE-2021-27645)
-
glibc: mq_notify does not handle separately allocated thread attributes (CVE-2021-33574)
For 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.
Additional Changes:
For detailed information on changes in this release, see the Red Hat Enterprise Linux 8.5 Release Notes linked from the References section.
- Solution:
For details on how to apply this update, which includes the changes described in this advisory, refer to:
https://access.redhat.com/articles/11258
For the update to take effect, all services linked to the glibc library must be restarted, or the system rebooted.
- Bugs fixed (https://bugzilla.redhat.com/):
1871386 - glibc: Update syscall names for Linux 5.6, 5.7, and 5.8. 1912670 - semctl SEM_STAT_ANY fails to pass the buffer specified by the caller to the kernel 1927877 - CVE-2021-27645 glibc: Use-after-free in addgetnetgrentX function in netgroupcache.c [rhel-8] 1930302 - glibc: provide IPPROTO_MPTCP definition 1932589 - CVE-2021-27645 glibc: Use-after-free in addgetnetgrentX function in netgroupcache.c 1935128 - glibc: Rebuild glibc after objcopy fix for bug 1928936 [rhel-8.5.0] 1965408 - CVE-2021-33574 glibc: mq_notify does not handle separately allocated thread attributes 1977975 - CVE-2021-35942 glibc: Arbitrary read in wordexp()
- Package List:
Red Hat Enterprise Linux AppStream (v. 8):
aarch64: compat-libpthread-nonshared-2.28-164.el8.aarch64.rpm glibc-debuginfo-2.28-164.el8.aarch64.rpm glibc-utils-2.28-164.el8.aarch64.rpm
ppc64le: compat-libpthread-nonshared-2.28-164.el8.ppc64le.rpm glibc-debuginfo-2.28-164.el8.ppc64le.rpm glibc-debuginfo-common-2.28-164.el8.ppc64le.rpm glibc-utils-2.28-164.el8.ppc64le.rpm
s390x: compat-libpthread-nonshared-2.28-164.el8.s390x.rpm glibc-debuginfo-2.28-164.el8.s390x.rpm glibc-debuginfo-common-2.28-164.el8.s390x.rpm glibc-utils-2.28-164.el8.s390x.rpm
x86_64: compat-libpthread-nonshared-2.28-164.el8.x86_64.rpm glibc-debuginfo-2.28-164.el8.x86_64.rpm glibc-debuginfo-common-2.28-164.el8.x86_64.rpm glibc-utils-2.28-164.el8.x86_64.rpm
Red Hat Enterprise Linux BaseOS (v. 8):
Source: glibc-2.28-164.el8.src.rpm
aarch64: glibc-2.28-164.el8.aarch64.rpm glibc-all-langpacks-2.28-164.el8.aarch64.rpm glibc-common-2.28-164.el8.aarch64.rpm glibc-debuginfo-2.28-164.el8.aarch64.rpm glibc-devel-2.28-164.el8.aarch64.rpm glibc-headers-2.28-164.el8.aarch64.rpm glibc-langpack-aa-2.28-164.el8.aarch64.rpm glibc-langpack-af-2.28-164.el8.aarch64.rpm glibc-langpack-agr-2.28-164.el8.aarch64.rpm glibc-langpack-ak-2.28-164.el8.aarch64.rpm glibc-langpack-am-2.28-164.el8.aarch64.rpm glibc-langpack-an-2.28-164.el8.aarch64.rpm glibc-langpack-anp-2.28-164.el8.aarch64.rpm glibc-langpack-ar-2.28-164.el8.aarch64.rpm glibc-langpack-as-2.28-164.el8.aarch64.rpm glibc-langpack-ast-2.28-164.el8.aarch64.rpm glibc-langpack-ayc-2.28-164.el8.aarch64.rpm glibc-langpack-az-2.28-164.el8.aarch64.rpm glibc-langpack-be-2.28-164.el8.aarch64.rpm glibc-langpack-bem-2.28-164.el8.aarch64.rpm glibc-langpack-ber-2.28-164.el8.aarch64.rpm glibc-langpack-bg-2.28-164.el8.aarch64.rpm glibc-langpack-bhb-2.28-164.el8.aarch64.rpm glibc-langpack-bho-2.28-164.el8.aarch64.rpm glibc-langpack-bi-2.28-164.el8.aarch64.rpm glibc-langpack-bn-2.28-164.el8.aarch64.rpm glibc-langpack-bo-2.28-164.el8.aarch64.rpm glibc-langpack-br-2.28-164.el8.aarch64.rpm glibc-langpack-brx-2.28-164.el8.aarch64.rpm glibc-langpack-bs-2.28-164.el8.aarch64.rpm glibc-langpack-byn-2.28-164.el8.aarch64.rpm glibc-langpack-ca-2.28-164.el8.aarch64.rpm glibc-langpack-ce-2.28-164.el8.aarch64.rpm glibc-langpack-chr-2.28-164.el8.aarch64.rpm glibc-langpack-cmn-2.28-164.el8.aarch64.rpm glibc-langpack-crh-2.28-164.el8.aarch64.rpm glibc-langpack-cs-2.28-164.el8.aarch64.rpm glibc-langpack-csb-2.28-164.el8.aarch64.rpm glibc-langpack-cv-2.28-164.el8.aarch64.rpm glibc-langpack-cy-2.28-164.el8.aarch64.rpm glibc-langpack-da-2.28-164.el8.aarch64.rpm glibc-langpack-de-2.28-164.el8.aarch64.rpm glibc-langpack-doi-2.28-164.el8.aarch64.rpm glibc-langpack-dsb-2.28-164.el8.aarch64.rpm glibc-langpack-dv-2.28-164.el8.aarch64.rpm glibc-langpack-dz-2.28-164.el8.aarch64.rpm glibc-langpack-el-2.28-164.el8.aarch64.rpm glibc-langpack-en-2.28-164.el8.aarch64.rpm glibc-langpack-eo-2.28-164.el8.aarch64.rpm glibc-langpack-es-2.28-164.el8.aarch64.rpm glibc-langpack-et-2.28-164.el8.aarch64.rpm glibc-langpack-eu-2.28-164.el8.aarch64.rpm glibc-langpack-fa-2.28-164.el8.aarch64.rpm glibc-langpack-ff-2.28-164.el8.aarch64.rpm glibc-langpack-fi-2.28-164.el8.aarch64.rpm glibc-langpack-fil-2.28-164.el8.aarch64.rpm glibc-langpack-fo-2.28-164.el8.aarch64.rpm glibc-langpack-fr-2.28-164.el8.aarch64.rpm glibc-langpack-fur-2.28-164.el8.aarch64.rpm glibc-langpack-fy-2.28-164.el8.aarch64.rpm glibc-langpack-ga-2.28-164.el8.aarch64.rpm glibc-langpack-gd-2.28-164.el8.aarch64.rpm glibc-langpack-gez-2.28-164.el8.aarch64.rpm glibc-langpack-gl-2.28-164.el8.aarch64.rpm glibc-langpack-gu-2.28-164.el8.aarch64.rpm glibc-langpack-gv-2.28-164.el8.aarch64.rpm glibc-langpack-ha-2.28-164.el8.aarch64.rpm glibc-langpack-hak-2.28-164.el8.aarch64.rpm glibc-langpack-he-2.28-164.el8.aarch64.rpm glibc-langpack-hi-2.28-164.el8.aarch64.rpm glibc-langpack-hif-2.28-164.el8.aarch64.rpm glibc-langpack-hne-2.28-164.el8.aarch64.rpm glibc-langpack-hr-2.28-164.el8.aarch64.rpm glibc-langpack-hsb-2.28-164.el8.aarch64.rpm glibc-langpack-ht-2.28-164.el8.aarch64.rpm glibc-langpack-hu-2.28-164.el8.aarch64.rpm glibc-langpack-hy-2.28-164.el8.aarch64.rpm glibc-langpack-ia-2.28-164.el8.aarch64.rpm glibc-langpack-id-2.28-164.el8.aarch64.rpm glibc-langpack-ig-2.28-164.el8.aarch64.rpm glibc-langpack-ik-2.28-164.el8.aarch64.rpm glibc-langpack-is-2.28-164.el8.aarch64.rpm glibc-langpack-it-2.28-164.el8.aarch64.rpm glibc-langpack-iu-2.28-164.el8.aarch64.rpm glibc-langpack-ja-2.28-164.el8.aarch64.rpm glibc-langpack-ka-2.28-164.el8.aarch64.rpm glibc-langpack-kab-2.28-164.el8.aarch64.rpm glibc-langpack-kk-2.28-164.el8.aarch64.rpm glibc-langpack-kl-2.28-164.el8.aarch64.rpm glibc-langpack-km-2.28-164.el8.aarch64.rpm glibc-langpack-kn-2.28-164.el8.aarch64.rpm glibc-langpack-ko-2.28-164.el8.aarch64.rpm glibc-langpack-kok-2.28-164.el8.aarch64.rpm glibc-langpack-ks-2.28-164.el8.aarch64.rpm glibc-langpack-ku-2.28-164.el8.aarch64.rpm glibc-langpack-kw-2.28-164.el8.aarch64.rpm glibc-langpack-ky-2.28-164.el8.aarch64.rpm glibc-langpack-lb-2.28-164.el8.aarch64.rpm glibc-langpack-lg-2.28-164.el8.aarch64.rpm glibc-langpack-li-2.28-164.el8.aarch64.rpm glibc-langpack-lij-2.28-164.el8.aarch64.rpm glibc-langpack-ln-2.28-164.el8.aarch64.rpm glibc-langpack-lo-2.28-164.el8.aarch64.rpm glibc-langpack-lt-2.28-164.el8.aarch64.rpm glibc-langpack-lv-2.28-164.el8.aarch64.rpm glibc-langpack-lzh-2.28-164.el8.aarch64.rpm glibc-langpack-mag-2.28-164.el8.aarch64.rpm glibc-langpack-mai-2.28-164.el8.aarch64.rpm glibc-langpack-mfe-2.28-164.el8.aarch64.rpm glibc-langpack-mg-2.28-164.el8.aarch64.rpm glibc-langpack-mhr-2.28-164.el8.aarch64.rpm glibc-langpack-mi-2.28-164.el8.aarch64.rpm glibc-langpack-miq-2.28-164.el8.aarch64.rpm glibc-langpack-mjw-2.28-164.el8.aarch64.rpm glibc-langpack-mk-2.28-164.el8.aarch64.rpm glibc-langpack-ml-2.28-164.el8.aarch64.rpm glibc-langpack-mn-2.28-164.el8.aarch64.rpm glibc-langpack-mni-2.28-164.el8.aarch64.rpm glibc-langpack-mr-2.28-164.el8.aarch64.rpm glibc-langpack-ms-2.28-164.el8.aarch64.rpm glibc-langpack-mt-2.28-164.el8.aarch64.rpm glibc-langpack-my-2.28-164.el8.aarch64.rpm glibc-langpack-nan-2.28-164.el8.aarch64.rpm glibc-langpack-nb-2.28-164.el8.aarch64.rpm glibc-langpack-nds-2.28-164.el8.aarch64.rpm glibc-langpack-ne-2.28-164.el8.aarch64.rpm glibc-langpack-nhn-2.28-164.el8.aarch64.rpm glibc-langpack-niu-2.28-164.el8.aarch64.rpm glibc-langpack-nl-2.28-164.el8.aarch64.rpm glibc-langpack-nn-2.28-164.el8.aarch64.rpm glibc-langpack-nr-2.28-164.el8.aarch64.rpm glibc-langpack-nso-2.28-164.el8.aarch64.rpm glibc-langpack-oc-2.28-164.el8.aarch64.rpm glibc-langpack-om-2.28-164.el8.aarch64.rpm glibc-langpack-or-2.28-164.el8.aarch64.rpm glibc-langpack-os-2.28-164.el8.aarch64.rpm glibc-langpack-pa-2.28-164.el8.aarch64.rpm glibc-langpack-pap-2.28-164.el8.aarch64.rpm glibc-langpack-pl-2.28-164.el8.aarch64.rpm glibc-langpack-ps-2.28-164.el8.aarch64.rpm glibc-langpack-pt-2.28-164.el8.aarch64.rpm glibc-langpack-quz-2.28-164.el8.aarch64.rpm glibc-langpack-raj-2.28-164.el8.aarch64.rpm glibc-langpack-ro-2.28-164.el8.aarch64.rpm glibc-langpack-ru-2.28-164.el8.aarch64.rpm glibc-langpack-rw-2.28-164.el8.aarch64.rpm glibc-langpack-sa-2.28-164.el8.aarch64.rpm glibc-langpack-sah-2.28-164.el8.aarch64.rpm glibc-langpack-sat-2.28-164.el8.aarch64.rpm glibc-langpack-sc-2.28-164.el8.aarch64.rpm glibc-langpack-sd-2.28-164.el8.aarch64.rpm glibc-langpack-se-2.28-164.el8.aarch64.rpm glibc-langpack-sgs-2.28-164.el8.aarch64.rpm glibc-langpack-shn-2.28-164.el8.aarch64.rpm glibc-langpack-shs-2.28-164.el8.aarch64.rpm glibc-langpack-si-2.28-164.el8.aarch64.rpm glibc-langpack-sid-2.28-164.el8.aarch64.rpm glibc-langpack-sk-2.28-164.el8.aarch64.rpm glibc-langpack-sl-2.28-164.el8.aarch64.rpm glibc-langpack-sm-2.28-164.el8.aarch64.rpm glibc-langpack-so-2.28-164.el8.aarch64.rpm glibc-langpack-sq-2.28-164.el8.aarch64.rpm glibc-langpack-sr-2.28-164.el8.aarch64.rpm glibc-langpack-ss-2.28-164.el8.aarch64.rpm glibc-langpack-st-2.28-164.el8.aarch64.rpm glibc-langpack-sv-2.28-164.el8.aarch64.rpm glibc-langpack-sw-2.28-164.el8.aarch64.rpm glibc-langpack-szl-2.28-164.el8.aarch64.rpm glibc-langpack-ta-2.28-164.el8.aarch64.rpm glibc-langpack-tcy-2.28-164.el8.aarch64.rpm glibc-langpack-te-2.28-164.el8.aarch64.rpm glibc-langpack-tg-2.28-164.el8.aarch64.rpm glibc-langpack-th-2.28-164.el8.aarch64.rpm glibc-langpack-the-2.28-164.el8.aarch64.rpm glibc-langpack-ti-2.28-164.el8.aarch64.rpm glibc-langpack-tig-2.28-164.el8.aarch64.rpm glibc-langpack-tk-2.28-164.el8.aarch64.rpm glibc-langpack-tl-2.28-164.el8.aarch64.rpm glibc-langpack-tn-2.28-164.el8.aarch64.rpm glibc-langpack-to-2.28-164.el8.aarch64.rpm glibc-langpack-tpi-2.28-164.el8.aarch64.rpm glibc-langpack-tr-2.28-164.el8.aarch64.rpm glibc-langpack-ts-2.28-164.el8.aarch64.rpm glibc-langpack-tt-2.28-164.el8.aarch64.rpm glibc-langpack-ug-2.28-164.el8.aarch64.rpm glibc-langpack-uk-2.28-164.el8.aarch64.rpm glibc-langpack-unm-2.28-164.el8.aarch64.rpm glibc-langpack-ur-2.28-164.el8.aarch64.rpm glibc-langpack-uz-2.28-164.el8.aarch64.rpm glibc-langpack-ve-2.28-164.el8.aarch64.rpm glibc-langpack-vi-2.28-164.el8.aarch64.rpm glibc-langpack-wa-2.28-164.el8.aarch64.rpm glibc-langpack-wae-2.28-164.el8.aarch64.rpm glibc-langpack-wal-2.28-164.el8.aarch64.rpm glibc-langpack-wo-2.28-164.el8.aarch64.rpm glibc-langpack-xh-2.28-164.el8.aarch64.rpm glibc-langpack-yi-2.28-164.el8.aarch64.rpm glibc-langpack-yo-2.28-164.el8.aarch64.rpm glibc-langpack-yue-2.28-164.el8.aarch64.rpm glibc-langpack-yuw-2.28-164.el8.aarch64.rpm glibc-langpack-zh-2.28-164.el8.aarch64.rpm glibc-langpack-zu-2.28-164.el8.aarch64.rpm glibc-locale-source-2.28-164.el8.aarch64.rpm glibc-minimal-langpack-2.28-164.el8.aarch64.rpm libnsl-2.28-164.el8.aarch64.rpm nscd-2.28-164.el8.aarch64.rpm nss_db-2.28-164.el8.aarch64.rpm
ppc64le: glibc-2.28-164.el8.ppc64le.rpm glibc-all-langpacks-2.28-164.el8.ppc64le.rpm glibc-common-2.28-164.el8.ppc64le.rpm glibc-debuginfo-2.28-164.el8.ppc64le.rpm glibc-debuginfo-common-2.28-164.el8.ppc64le.rpm glibc-devel-2.28-164.el8.ppc64le.rpm glibc-headers-2.28-164.el8.ppc64le.rpm glibc-langpack-aa-2.28-164.el8.ppc64le.rpm glibc-langpack-af-2.28-164.el8.ppc64le.rpm glibc-langpack-agr-2.28-164.el8.ppc64le.rpm glibc-langpack-ak-2.28-164.el8.ppc64le.rpm glibc-langpack-am-2.28-164.el8.ppc64le.rpm glibc-langpack-an-2.28-164.el8.ppc64le.rpm glibc-langpack-anp-2.28-164.el8.ppc64le.rpm glibc-langpack-ar-2.28-164.el8.ppc64le.rpm glibc-langpack-as-2.28-164.el8.ppc64le.rpm glibc-langpack-ast-2.28-164.el8.ppc64le.rpm glibc-langpack-ayc-2.28-164.el8.ppc64le.rpm glibc-langpack-az-2.28-164.el8.ppc64le.rpm glibc-langpack-be-2.28-164.el8.ppc64le.rpm glibc-langpack-bem-2.28-164.el8.ppc64le.rpm glibc-langpack-ber-2.28-164.el8.ppc64le.rpm glibc-langpack-bg-2.28-164.el8.ppc64le.rpm glibc-langpack-bhb-2.28-164.el8.ppc64le.rpm glibc-langpack-bho-2.28-164.el8.ppc64le.rpm glibc-langpack-bi-2.28-164.el8.ppc64le.rpm glibc-langpack-bn-2.28-164.el8.ppc64le.rpm glibc-langpack-bo-2.28-164.el8.ppc64le.rpm glibc-langpack-br-2.28-164.el8.ppc64le.rpm glibc-langpack-brx-2.28-164.el8.ppc64le.rpm glibc-langpack-bs-2.28-164.el8.ppc64le.rpm glibc-langpack-byn-2.28-164.el8.ppc64le.rpm glibc-langpack-ca-2.28-164.el8.ppc64le.rpm glibc-langpack-ce-2.28-164.el8.ppc64le.rpm glibc-langpack-chr-2.28-164.el8.ppc64le.rpm glibc-langpack-cmn-2.28-164.el8.ppc64le.rpm glibc-langpack-crh-2.28-164.el8.ppc64le.rpm glibc-langpack-cs-2.28-164.el8.ppc64le.rpm glibc-langpack-csb-2.28-164.el8.ppc64le.rpm glibc-langpack-cv-2.28-164.el8.ppc64le.rpm glibc-langpack-cy-2.28-164.el8.ppc64le.rpm glibc-langpack-da-2.28-164.el8.ppc64le.rpm glibc-langpack-de-2.28-164.el8.ppc64le.rpm glibc-langpack-doi-2.28-164.el8.ppc64le.rpm glibc-langpack-dsb-2.28-164.el8.ppc64le.rpm glibc-langpack-dv-2.28-164.el8.ppc64le.rpm glibc-langpack-dz-2.28-164.el8.ppc64le.rpm glibc-langpack-el-2.28-164.el8.ppc64le.rpm glibc-langpack-en-2.28-164.el8.ppc64le.rpm glibc-langpack-eo-2.28-164.el8.ppc64le.rpm glibc-langpack-es-2.28-164.el8.ppc64le.rpm glibc-langpack-et-2.28-164.el8.ppc64le.rpm glibc-langpack-eu-2.28-164.el8.ppc64le.rpm glibc-langpack-fa-2.28-164.el8.ppc64le.rpm glibc-langpack-ff-2.28-164.el8.ppc64le.rpm glibc-langpack-fi-2.28-164.el8.ppc64le.rpm glibc-langpack-fil-2.28-164.el8.ppc64le.rpm glibc-langpack-fo-2.28-164.el8.ppc64le.rpm glibc-langpack-fr-2.28-164.el8.ppc64le.rpm glibc-langpack-fur-2.28-164.el8.ppc64le.rpm glibc-langpack-fy-2.28-164.el8.ppc64le.rpm glibc-langpack-ga-2.28-164.el8.ppc64le.rpm glibc-langpack-gd-2.28-164.el8.ppc64le.rpm glibc-langpack-gez-2.28-164.el8.ppc64le.rpm glibc-langpack-gl-2.28-164.el8.ppc64le.rpm glibc-langpack-gu-2.28-164.el8.ppc64le.rpm glibc-langpack-gv-2.28-164.el8.ppc64le.rpm glibc-langpack-ha-2.28-164.el8.ppc64le.rpm glibc-langpack-hak-2.28-164.el8.ppc64le.rpm glibc-langpack-he-2.28-164.el8.ppc64le.rpm glibc-langpack-hi-2.28-164.el8.ppc64le.rpm glibc-langpack-hif-2.28-164.el8.ppc64le.rpm glibc-langpack-hne-2.28-164.el8.ppc64le.rpm glibc-langpack-hr-2.28-164.el8.ppc64le.rpm glibc-langpack-hsb-2.28-164.el8.ppc64le.rpm glibc-langpack-ht-2.28-164.el8.ppc64le.rpm glibc-langpack-hu-2.28-164.el8.ppc64le.rpm glibc-langpack-hy-2.28-164.el8.ppc64le.rpm glibc-langpack-ia-2.28-164.el8.ppc64le.rpm glibc-langpack-id-2.28-164.el8.ppc64le.rpm glibc-langpack-ig-2.28-164.el8.ppc64le.rpm glibc-langpack-ik-2.28-164.el8.ppc64le.rpm glibc-langpack-is-2.28-164.el8.ppc64le.rpm glibc-langpack-it-2.28-164.el8.ppc64le.rpm glibc-langpack-iu-2.28-164.el8.ppc64le.rpm glibc-langpack-ja-2.28-164.el8.ppc64le.rpm glibc-langpack-ka-2.28-164.el8.ppc64le.rpm glibc-langpack-kab-2.28-164.el8.ppc64le.rpm glibc-langpack-kk-2.28-164.el8.ppc64le.rpm glibc-langpack-kl-2.28-164.el8.ppc64le.rpm glibc-langpack-km-2.28-164.el8.ppc64le.rpm glibc-langpack-kn-2.28-164.el8.ppc64le.rpm glibc-langpack-ko-2.28-164.el8.ppc64le.rpm glibc-langpack-kok-2.28-164.el8.ppc64le.rpm glibc-langpack-ks-2.28-164.el8.ppc64le.rpm glibc-langpack-ku-2.28-164.el8.ppc64le.rpm glibc-langpack-kw-2.28-164.el8.ppc64le.rpm glibc-langpack-ky-2.28-164.el8.ppc64le.rpm glibc-langpack-lb-2.28-164.el8.ppc64le.rpm glibc-langpack-lg-2.28-164.el8.ppc64le.rpm glibc-langpack-li-2.28-164.el8.ppc64le.rpm glibc-langpack-lij-2.28-164.el8.ppc64le.rpm glibc-langpack-ln-2.28-164.el8.ppc64le.rpm glibc-langpack-lo-2.28-164.el8.ppc64le.rpm glibc-langpack-lt-2.28-164.el8.ppc64le.rpm glibc-langpack-lv-2.28-164.el8.ppc64le.rpm glibc-langpack-lzh-2.28-164.el8.ppc64le.rpm glibc-langpack-mag-2.28-164.el8.ppc64le.rpm glibc-langpack-mai-2.28-164.el8.ppc64le.rpm glibc-langpack-mfe-2.28-164.el8.ppc64le.rpm glibc-langpack-mg-2.28-164.el8.ppc64le.rpm glibc-langpack-mhr-2.28-164.el8.ppc64le.rpm glibc-langpack-mi-2.28-164.el8.ppc64le.rpm glibc-langpack-miq-2.28-164.el8.ppc64le.rpm glibc-langpack-mjw-2.28-164.el8.ppc64le.rpm glibc-langpack-mk-2.28-164.el8.ppc64le.rpm glibc-langpack-ml-2.28-164.el8.ppc64le.rpm glibc-langpack-mn-2.28-164.el8.ppc64le.rpm glibc-langpack-mni-2.28-164.el8.ppc64le.rpm glibc-langpack-mr-2.28-164.el8.ppc64le.rpm glibc-langpack-ms-2.28-164.el8.ppc64le.rpm glibc-langpack-mt-2.28-164.el8.ppc64le.rpm glibc-langpack-my-2.28-164.el8.ppc64le.rpm glibc-langpack-nan-2.28-164.el8.ppc64le.rpm glibc-langpack-nb-2.28-164.el8.ppc64le.rpm glibc-langpack-nds-2.28-164.el8.ppc64le.rpm glibc-langpack-ne-2.28-164.el8.ppc64le.rpm glibc-langpack-nhn-2.28-164.el8.ppc64le.rpm glibc-langpack-niu-2.28-164.el8.ppc64le.rpm glibc-langpack-nl-2.28-164.el8.ppc64le.rpm glibc-langpack-nn-2.28-164.el8.ppc64le.rpm glibc-langpack-nr-2.28-164.el8.ppc64le.rpm glibc-langpack-nso-2.28-164.el8.ppc64le.rpm glibc-langpack-oc-2.28-164.el8.ppc64le.rpm glibc-langpack-om-2.28-164.el8.ppc64le.rpm glibc-langpack-or-2.28-164.el8.ppc64le.rpm glibc-langpack-os-2.28-164.el8.ppc64le.rpm glibc-langpack-pa-2.28-164.el8.ppc64le.rpm glibc-langpack-pap-2.28-164.el8.ppc64le.rpm glibc-langpack-pl-2.28-164.el8.ppc64le.rpm glibc-langpack-ps-2.28-164.el8.ppc64le.rpm glibc-langpack-pt-2.28-164.el8.ppc64le.rpm glibc-langpack-quz-2.28-164.el8.ppc64le.rpm glibc-langpack-raj-2.28-164.el8.ppc64le.rpm glibc-langpack-ro-2.28-164.el8.ppc64le.rpm glibc-langpack-ru-2.28-164.el8.ppc64le.rpm glibc-langpack-rw-2.28-164.el8.ppc64le.rpm glibc-langpack-sa-2.28-164.el8.ppc64le.rpm glibc-langpack-sah-2.28-164.el8.ppc64le.rpm glibc-langpack-sat-2.28-164.el8.ppc64le.rpm glibc-langpack-sc-2.28-164.el8.ppc64le.rpm glibc-langpack-sd-2.28-164.el8.ppc64le.rpm glibc-langpack-se-2.28-164.el8.ppc64le.rpm glibc-langpack-sgs-2.28-164.el8.ppc64le.rpm glibc-langpack-shn-2.28-164.el8.ppc64le.rpm glibc-langpack-shs-2.28-164.el8.ppc64le.rpm glibc-langpack-si-2.28-164.el8.ppc64le.rpm glibc-langpack-sid-2.28-164.el8.ppc64le.rpm glibc-langpack-sk-2.28-164.el8.ppc64le.rpm glibc-langpack-sl-2.28-164.el8.ppc64le.rpm glibc-langpack-sm-2.28-164.el8.ppc64le.rpm glibc-langpack-so-2.28-164.el8.ppc64le.rpm glibc-langpack-sq-2.28-164.el8.ppc64le.rpm glibc-langpack-sr-2.28-164.el8.ppc64le.rpm glibc-langpack-ss-2.28-164.el8.ppc64le.rpm glibc-langpack-st-2.28-164.el8.ppc64le.rpm glibc-langpack-sv-2.28-164.el8.ppc64le.rpm glibc-langpack-sw-2.28-164.el8.ppc64le.rpm glibc-langpack-szl-2.28-164.el8.ppc64le.rpm glibc-langpack-ta-2.28-164.el8.ppc64le.rpm glibc-langpack-tcy-2.28-164.el8.ppc64le.rpm glibc-langpack-te-2.28-164.el8.ppc64le.rpm glibc-langpack-tg-2.28-164.el8.ppc64le.rpm glibc-langpack-th-2.28-164.el8.ppc64le.rpm glibc-langpack-the-2.28-164.el8.ppc64le.rpm glibc-langpack-ti-2.28-164.el8.ppc64le.rpm glibc-langpack-tig-2.28-164.el8.ppc64le.rpm glibc-langpack-tk-2.28-164.el8.ppc64le.rpm glibc-langpack-tl-2.28-164.el8.ppc64le.rpm glibc-langpack-tn-2.28-164.el8.ppc64le.rpm glibc-langpack-to-2.28-164.el8.ppc64le.rpm glibc-langpack-tpi-2.28-164.el8.ppc64le.rpm glibc-langpack-tr-2.28-164.el8.ppc64le.rpm glibc-langpack-ts-2.28-164.el8.ppc64le.rpm glibc-langpack-tt-2.28-164.el8.ppc64le.rpm glibc-langpack-ug-2.28-164.el8.ppc64le.rpm glibc-langpack-uk-2.28-164.el8.ppc64le.rpm glibc-langpack-unm-2.28-164.el8.ppc64le.rpm glibc-langpack-ur-2.28-164.el8.ppc64le.rpm glibc-langpack-uz-2.28-164.el8.ppc64le.rpm glibc-langpack-ve-2.28-164.el8.ppc64le.rpm glibc-langpack-vi-2.28-164.el8.ppc64le.rpm glibc-langpack-wa-2.28-164.el8.ppc64le.rpm glibc-langpack-wae-2.28-164.el8.ppc64le.rpm glibc-langpack-wal-2.28-164.el8.ppc64le.rpm glibc-langpack-wo-2.28-164.el8.ppc64le.rpm glibc-langpack-xh-2.28-164.el8.ppc64le.rpm glibc-langpack-yi-2.28-164.el8.ppc64le.rpm glibc-langpack-yo-2.28-164.el8.ppc64le.rpm glibc-langpack-yue-2.28-164.el8.ppc64le.rpm glibc-langpack-yuw-2.28-164.el8.ppc64le.rpm glibc-langpack-zh-2.28-164.el8.ppc64le.rpm glibc-langpack-zu-2.28-164.el8.ppc64le.rpm glibc-locale-source-2.28-164.el8.ppc64le.rpm glibc-minimal-langpack-2.28-164.el8.ppc64le.rpm libnsl-2.28-164.el8.ppc64le.rpm nscd-2.28-164.el8.ppc64le.rpm nss_db-2.28-164.el8.ppc64le.rpm
s390x: glibc-2.28-164.el8.s390x.rpm glibc-all-langpacks-2.28-164.el8.s390x.rpm glibc-common-2.28-164.el8.s390x.rpm glibc-debuginfo-2.28-164.el8.s390x.rpm glibc-debuginfo-common-2.28-164.el8.s390x.rpm glibc-devel-2.28-164.el8.s390x.rpm glibc-headers-2.28-164.el8.s390x.rpm glibc-langpack-aa-2.28-164.el8.s390x.rpm glibc-langpack-af-2.28-164.el8.s390x.rpm glibc-langpack-agr-2.28-164.el8.s390x.rpm glibc-langpack-ak-2.28-164.el8.s390x.rpm glibc-langpack-am-2.28-164.el8.s390x.rpm glibc-langpack-an-2.28-164.el8.s390x.rpm glibc-langpack-anp-2.28-164.el8.s390x.rpm glibc-langpack-ar-2.28-164.el8.s390x.rpm glibc-langpack-as-2.28-164.el8.s390x.rpm glibc-langpack-ast-2.28-164.el8.s390x.rpm glibc-langpack-ayc-2.28-164.el8.s390x.rpm glibc-langpack-az-2.28-164.el8.s390x.rpm glibc-langpack-be-2.28-164.el8.s390x.rpm glibc-langpack-bem-2.28-164.el8.s390x.rpm glibc-langpack-ber-2.28-164.el8.s390x.rpm glibc-langpack-bg-2.28-164.el8.s390x.rpm glibc-langpack-bhb-2.28-164.el8.s390x.rpm glibc-langpack-bho-2.28-164.el8.s390x.rpm glibc-langpack-bi-2.28-164.el8.s390x.rpm glibc-langpack-bn-2.28-164.el8.s390x.rpm glibc-langpack-bo-2.28-164.el8.s390x.rpm glibc-langpack-br-2.28-164.el8.s390x.rpm glibc-langpack-brx-2.28-164.el8.s390x.rpm glibc-langpack-bs-2.28-164.el8.s390x.rpm glibc-langpack-byn-2.28-164.el8.s390x.rpm glibc-langpack-ca-2.28-164.el8.s390x.rpm glibc-langpack-ce-2.28-164.el8.s390x.rpm glibc-langpack-chr-2.28-164.el8.s390x.rpm glibc-langpack-cmn-2.28-164.el8.s390x.rpm glibc-langpack-crh-2.28-164.el8.s390x.rpm glibc-langpack-cs-2.28-164.el8.s390x.rpm glibc-langpack-csb-2.28-164.el8.s390x.rpm glibc-langpack-cv-2.28-164.el8.s390x.rpm glibc-langpack-cy-2.28-164.el8.s390x.rpm glibc-langpack-da-2.28-164.el8.s390x.rpm glibc-langpack-de-2.28-164.el8.s390x.rpm glibc-langpack-doi-2.28-164.el8.s390x.rpm glibc-langpack-dsb-2.28-164.el8.s390x.rpm glibc-langpack-dv-2.28-164.el8.s390x.rpm glibc-langpack-dz-2.28-164.el8.s390x.rpm glibc-langpack-el-2.28-164.el8.s390x.rpm glibc-langpack-en-2.28-164.el8.s390x.rpm glibc-langpack-eo-2.28-164.el8.s390x.rpm glibc-langpack-es-2.28-164.el8.s390x.rpm glibc-langpack-et-2.28-164.el8.s390x.rpm glibc-langpack-eu-2.28-164.el8.s390x.rpm glibc-langpack-fa-2.28-164.el8.s390x.rpm glibc-langpack-ff-2.28-164.el8.s390x.rpm glibc-langpack-fi-2.28-164.el8.s390x.rpm glibc-langpack-fil-2.28-164.el8.s390x.rpm glibc-langpack-fo-2.28-164.el8.s390x.rpm glibc-langpack-fr-2.28-164.el8.s390x.rpm glibc-langpack-fur-2.28-164.el8.s390x.rpm glibc-langpack-fy-2.28-164.el8.s390x.rpm glibc-langpack-ga-2.28-164.el8.s390x.rpm glibc-langpack-gd-2.28-164.el8.s390x.rpm glibc-langpack-gez-2.28-164.el8.s390x.rpm glibc-langpack-gl-2.28-164.el8.s390x.rpm glibc-langpack-gu-2.28-164.el8.s390x.rpm glibc-langpack-gv-2.28-164.el8.s390x.rpm glibc-langpack-ha-2.28-164.el8.s390x.rpm glibc-langpack-hak-2.28-164.el8.s390x.rpm glibc-langpack-he-2.28-164.el8.s390x.rpm glibc-langpack-hi-2.28-164.el8.s390x.rpm glibc-langpack-hif-2.28-164.el8.s390x.rpm glibc-langpack-hne-2.28-164.el8.s390x.rpm glibc-langpack-hr-2.28-164.el8.s390x.rpm glibc-langpack-hsb-2.28-164.el8.s390x.rpm glibc-langpack-ht-2.28-164.el8.s390x.rpm glibc-langpack-hu-2.28-164.el8.s390x.rpm glibc-langpack-hy-2.28-164.el8.s390x.rpm glibc-langpack-ia-2.28-164.el8.s390x.rpm glibc-langpack-id-2.28-164.el8.s390x.rpm glibc-langpack-ig-2.28-164.el8.s390x.rpm glibc-langpack-ik-2.28-164.el8.s390x.rpm glibc-langpack-is-2.28-164.el8.s390x.rpm glibc-langpack-it-2.28-164.el8.s390x.rpm glibc-langpack-iu-2.28-164.el8.s390x.rpm glibc-langpack-ja-2.28-164.el8.s390x.rpm glibc-langpack-ka-2.28-164.el8.s390x.rpm glibc-langpack-kab-2.28-164.el8.s390x.rpm glibc-langpack-kk-2.28-164.el8.s390x.rpm glibc-langpack-kl-2.28-164.el8.s390x.rpm glibc-langpack-km-2.28-164.el8.s390x.rpm glibc-langpack-kn-2.28-164.el8.s390x.rpm glibc-langpack-ko-2.28-164.el8.s390x.rpm glibc-langpack-kok-2.28-164.el8.s390x.rpm glibc-langpack-ks-2.28-164.el8.s390x.rpm glibc-langpack-ku-2.28-164.el8.s390x.rpm glibc-langpack-kw-2.28-164.el8.s390x.rpm glibc-langpack-ky-2.28-164.el8.s390x.rpm glibc-langpack-lb-2.28-164.el8.s390x.rpm glibc-langpack-lg-2.28-164.el8.s390x.rpm glibc-langpack-li-2.28-164.el8.s390x.rpm glibc-langpack-lij-2.28-164.el8.s390x.rpm glibc-langpack-ln-2.28-164.el8.s390x.rpm glibc-langpack-lo-2.28-164.el8.s390x.rpm glibc-langpack-lt-2.28-164.el8.s390x.rpm glibc-langpack-lv-2.28-164.el8.s390x.rpm glibc-langpack-lzh-2.28-164.el8.s390x.rpm glibc-langpack-mag-2.28-164.el8.s390x.rpm glibc-langpack-mai-2.28-164.el8.s390x.rpm glibc-langpack-mfe-2.28-164.el8.s390x.rpm glibc-langpack-mg-2.28-164.el8.s390x.rpm glibc-langpack-mhr-2.28-164.el8.s390x.rpm glibc-langpack-mi-2.28-164.el8.s390x.rpm glibc-langpack-miq-2.28-164.el8.s390x.rpm glibc-langpack-mjw-2.28-164.el8.s390x.rpm glibc-langpack-mk-2.28-164.el8.s390x.rpm glibc-langpack-ml-2.28-164.el8.s390x.rpm glibc-langpack-mn-2.28-164.el8.s390x.rpm glibc-langpack-mni-2.28-164.el8.s390x.rpm glibc-langpack-mr-2.28-164.el8.s390x.rpm glibc-langpack-ms-2.28-164.el8.s390x.rpm glibc-langpack-mt-2.28-164.el8.s390x.rpm glibc-langpack-my-2.28-164.el8.s390x.rpm glibc-langpack-nan-2.28-164.el8.s390x.rpm glibc-langpack-nb-2.28-164.el8.s390x.rpm glibc-langpack-nds-2.28-164.el8.s390x.rpm glibc-langpack-ne-2.28-164.el8.s390x.rpm glibc-langpack-nhn-2.28-164.el8.s390x.rpm glibc-langpack-niu-2.28-164.el8.s390x.rpm glibc-langpack-nl-2.28-164.el8.s390x.rpm glibc-langpack-nn-2.28-164.el8.s390x.rpm glibc-langpack-nr-2.28-164.el8.s390x.rpm glibc-langpack-nso-2.28-164.el8.s390x.rpm glibc-langpack-oc-2.28-164.el8.s390x.rpm glibc-langpack-om-2.28-164.el8.s390x.rpm glibc-langpack-or-2.28-164.el8.s390x.rpm glibc-langpack-os-2.28-164.el8.s390x.rpm glibc-langpack-pa-2.28-164.el8.s390x.rpm glibc-langpack-pap-2.28-164.el8.s390x.rpm glibc-langpack-pl-2.28-164.el8.s390x.rpm glibc-langpack-ps-2.28-164.el8.s390x.rpm glibc-langpack-pt-2.28-164.el8.s390x.rpm glibc-langpack-quz-2.28-164.el8.s390x.rpm glibc-langpack-raj-2.28-164.el8.s390x.rpm glibc-langpack-ro-2.28-164.el8.s390x.rpm glibc-langpack-ru-2.28-164.el8.s390x.rpm glibc-langpack-rw-2.28-164.el8.s390x.rpm glibc-langpack-sa-2.28-164.el8.s390x.rpm glibc-langpack-sah-2.28-164.el8.s390x.rpm glibc-langpack-sat-2.28-164.el8.s390x.rpm glibc-langpack-sc-2.28-164.el8.s390x.rpm glibc-langpack-sd-2.28-164.el8.s390x.rpm glibc-langpack-se-2.28-164.el8.s390x.rpm glibc-langpack-sgs-2.28-164.el8.s390x.rpm glibc-langpack-shn-2.28-164.el8.s390x.rpm glibc-langpack-shs-2.28-164.el8.s390x.rpm glibc-langpack-si-2.28-164.el8.s390x.rpm glibc-langpack-sid-2.28-164.el8.s390x.rpm glibc-langpack-sk-2.28-164.el8.s390x.rpm glibc-langpack-sl-2.28-164.el8.s390x.rpm glibc-langpack-sm-2.28-164.el8.s390x.rpm glibc-langpack-so-2.28-164.el8.s390x.rpm glibc-langpack-sq-2.28-164.el8.s390x.rpm glibc-langpack-sr-2.28-164.el8.s390x.rpm glibc-langpack-ss-2.28-164.el8.s390x.rpm glibc-langpack-st-2.28-164.el8.s390x.rpm glibc-langpack-sv-2.28-164.el8.s390x.rpm glibc-langpack-sw-2.28-164.el8.s390x.rpm glibc-langpack-szl-2.28-164.el8.s390x.rpm glibc-langpack-ta-2.28-164.el8.s390x.rpm glibc-langpack-tcy-2.28-164.el8.s390x.rpm glibc-langpack-te-2.28-164.el8.s390x.rpm glibc-langpack-tg-2.28-164.el8.s390x.rpm glibc-langpack-th-2.28-164.el8.s390x.rpm glibc-langpack-the-2.28-164.el8.s390x.rpm glibc-langpack-ti-2.28-164.el8.s390x.rpm glibc-langpack-tig-2.28-164.el8.s390x.rpm glibc-langpack-tk-2.28-164.el8.s390x.rpm glibc-langpack-tl-2.28-164.el8.s390x.rpm glibc-langpack-tn-2.28-164.el8.s390x.rpm glibc-langpack-to-2.28-164.el8.s390x.rpm glibc-langpack-tpi-2.28-164.el8.s390x.rpm glibc-langpack-tr-2.28-164.el8.s390x.rpm glibc-langpack-ts-2.28-164.el8.s390x.rpm glibc-langpack-tt-2.28-164.el8.s390x.rpm glibc-langpack-ug-2.28-164.el8.s390x.rpm glibc-langpack-uk-2.28-164.el8.s390x.rpm glibc-langpack-unm-2.28-164.el8.s390x.rpm glibc-langpack-ur-2.28-164.el8.s390x.rpm glibc-langpack-uz-2.28-164.el8.s390x.rpm glibc-langpack-ve-2.28-164.el8.s390x.rpm glibc-langpack-vi-2.28-164.el8.s390x.rpm glibc-langpack-wa-2.28-164.el8.s390x.rpm glibc-langpack-wae-2.28-164.el8.s390x.rpm glibc-langpack-wal-2.28-164.el8.s390x.rpm glibc-langpack-wo-2.28-164.el8.s390x.rpm glibc-langpack-xh-2.28-164.el8.s390x.rpm glibc-langpack-yi-2.28-164.el8.s390x.rpm glibc-langpack-yo-2.28-164.el8.s390x.rpm glibc-langpack-yue-2.28-164.el8.s390x.rpm glibc-langpack-yuw-2.28-164.el8.s390x.rpm glibc-langpack-zh-2.28-164.el8.s390x.rpm glibc-langpack-zu-2.28-164.el8.s390x.rpm glibc-locale-source-2.28-164.el8.s390x.rpm glibc-minimal-langpack-2.28-164.el8.s390x.rpm libnsl-2.28-164.el8.s390x.rpm nscd-2.28-164.el8.s390x.rpm nss_db-2.28-164.el8.s390x.rpm
x86_64: glibc-2.28-164.el8.i686.rpm glibc-2.28-164.el8.x86_64.rpm glibc-all-langpacks-2.28-164.el8.x86_64.rpm glibc-common-2.28-164.el8.x86_64.rpm glibc-debuginfo-2.28-164.el8.i686.rpm glibc-debuginfo-2.28-164.el8.x86_64.rpm glibc-debuginfo-common-2.28-164.el8.i686.rpm glibc-debuginfo-common-2.28-164.el8.x86_64.rpm glibc-devel-2.28-164.el8.i686.rpm glibc-devel-2.28-164.el8.x86_64.rpm glibc-headers-2.28-164.el8.i686.rpm glibc-headers-2.28-164.el8.x86_64.rpm glibc-langpack-aa-2.28-164.el8.x86_64.rpm glibc-langpack-af-2.28-164.el8.x86_64.rpm glibc-langpack-agr-2.28-164.el8.x86_64.rpm glibc-langpack-ak-2.28-164.el8.x86_64.rpm glibc-langpack-am-2.28-164.el8.x86_64.rpm glibc-langpack-an-2.28-164.el8.x86_64.rpm glibc-langpack-anp-2.28-164.el8.x86_64.rpm glibc-langpack-ar-2.28-164.el8.x86_64.rpm glibc-langpack-as-2.28-164.el8.x86_64.rpm glibc-langpack-ast-2.28-164.el8.x86_64.rpm glibc-langpack-ayc-2.28-164.el8.x86_64.rpm glibc-langpack-az-2.28-164.el8.x86_64.rpm glibc-langpack-be-2.28-164.el8.x86_64.rpm glibc-langpack-bem-2.28-164.el8.x86_64.rpm glibc-langpack-ber-2.28-164.el8.x86_64.rpm glibc-langpack-bg-2.28-164.el8.x86_64.rpm glibc-langpack-bhb-2.28-164.el8.x86_64.rpm glibc-langpack-bho-2.28-164.el8.x86_64.rpm glibc-langpack-bi-2.28-164.el8.x86_64.rpm glibc-langpack-bn-2.28-164.el8.x86_64.rpm glibc-langpack-bo-2.28-164.el8.x86_64.rpm glibc-langpack-br-2.28-164.el8.x86_64.rpm glibc-langpack-brx-2.28-164.el8.x86_64.rpm glibc-langpack-bs-2.28-164.el8.x86_64.rpm glibc-langpack-byn-2.28-164.el8.x86_64.rpm glibc-langpack-ca-2.28-164.el8.x86_64.rpm glibc-langpack-ce-2.28-164.el8.x86_64.rpm glibc-langpack-chr-2.28-164.el8.x86_64.rpm glibc-langpack-cmn-2.28-164.el8.x86_64.rpm glibc-langpack-crh-2.28-164.el8.x86_64.rpm glibc-langpack-cs-2.28-164.el8.x86_64.rpm glibc-langpack-csb-2.28-164.el8.x86_64.rpm glibc-langpack-cv-2.28-164.el8.x86_64.rpm glibc-langpack-cy-2.28-164.el8.x86_64.rpm glibc-langpack-da-2.28-164.el8.x86_64.rpm glibc-langpack-de-2.28-164.el8.x86_64.rpm glibc-langpack-doi-2.28-164.el8.x86_64.rpm glibc-langpack-dsb-2.28-164.el8.x86_64.rpm glibc-langpack-dv-2.28-164.el8.x86_64.rpm glibc-langpack-dz-2.28-164.el8.x86_64.rpm glibc-langpack-el-2.28-164.el8.x86_64.rpm glibc-langpack-en-2.28-164.el8.x86_64.rpm glibc-langpack-eo-2.28-164.el8.x86_64.rpm glibc-langpack-es-2.28-164.el8.x86_64.rpm glibc-langpack-et-2.28-164.el8.x86_64.rpm glibc-langpack-eu-2.28-164.el8.x86_64.rpm glibc-langpack-fa-2.28-164.el8.x86_64.rpm glibc-langpack-ff-2.28-164.el8.x86_64.rpm glibc-langpack-fi-2.28-164.el8.x86_64.rpm glibc-langpack-fil-2.28-164.el8.x86_64.rpm glibc-langpack-fo-2.28-164.el8.x86_64.rpm glibc-langpack-fr-2.28-164.el8.x86_64.rpm glibc-langpack-fur-2.28-164.el8.x86_64.rpm glibc-langpack-fy-2.28-164.el8.x86_64.rpm glibc-langpack-ga-2.28-164.el8.x86_64.rpm glibc-langpack-gd-2.28-164.el8.x86_64.rpm glibc-langpack-gez-2.28-164.el8.x86_64.rpm glibc-langpack-gl-2.28-164.el8.x86_64.rpm glibc-langpack-gu-2.28-164.el8.x86_64.rpm glibc-langpack-gv-2.28-164.el8.x86_64.rpm glibc-langpack-ha-2.28-164.el8.x86_64.rpm glibc-langpack-hak-2.28-164.el8.x86_64.rpm glibc-langpack-he-2.28-164.el8.x86_64.rpm glibc-langpack-hi-2.28-164.el8.x86_64.rpm glibc-langpack-hif-2.28-164.el8.x86_64.rpm glibc-langpack-hne-2.28-164.el8.x86_64.rpm glibc-langpack-hr-2.28-164.el8.x86_64.rpm glibc-langpack-hsb-2.28-164.el8.x86_64.rpm glibc-langpack-ht-2.28-164.el8.x86_64.rpm glibc-langpack-hu-2.28-164.el8.x86_64.rpm glibc-langpack-hy-2.28-164.el8.x86_64.rpm glibc-langpack-ia-2.28-164.el8.x86_64.rpm glibc-langpack-id-2.28-164.el8.x86_64.rpm glibc-langpack-ig-2.28-164.el8.x86_64.rpm glibc-langpack-ik-2.28-164.el8.x86_64.rpm glibc-langpack-is-2.28-164.el8.x86_64.rpm glibc-langpack-it-2.28-164.el8.x86_64.rpm glibc-langpack-iu-2.28-164.el8.x86_64.rpm glibc-langpack-ja-2.28-164.el8.x86_64.rpm glibc-langpack-ka-2.28-164.el8.x86_64.rpm glibc-langpack-kab-2.28-164.el8.x86_64.rpm glibc-langpack-kk-2.28-164.el8.x86_64.rpm glibc-langpack-kl-2.28-164.el8.x86_64.rpm glibc-langpack-km-2.28-164.el8.x86_64.rpm glibc-langpack-kn-2.28-164.el8.x86_64.rpm glibc-langpack-ko-2.28-164.el8.x86_64.rpm glibc-langpack-kok-2.28-164.el8.x86_64.rpm glibc-langpack-ks-2.28-164.el8.x86_64.rpm glibc-langpack-ku-2.28-164.el8.x86_64.rpm glibc-langpack-kw-2.28-164.el8.x86_64.rpm glibc-langpack-ky-2.28-164.el8.x86_64.rpm glibc-langpack-lb-2.28-164.el8.x86_64.rpm glibc-langpack-lg-2.28-164.el8.x86_64.rpm glibc-langpack-li-2.28-164.el8.x86_64.rpm glibc-langpack-lij-2.28-164.el8.x86_64.rpm glibc-langpack-ln-2.28-164.el8.x86_64.rpm glibc-langpack-lo-2.28-164.el8.x86_64.rpm glibc-langpack-lt-2.28-164.el8.x86_64.rpm glibc-langpack-lv-2.28-164.el8.x86_64.rpm glibc-langpack-lzh-2.28-164.el8.x86_64.rpm glibc-langpack-mag-2.28-164.el8.x86_64.rpm glibc-langpack-mai-2.28-164.el8.x86_64.rpm glibc-langpack-mfe-2.28-164.el8.x86_64.rpm glibc-langpack-mg-2.28-164.el8.x86_64.rpm glibc-langpack-mhr-2.28-164.el8.x86_64.rpm glibc-langpack-mi-2.28-164.el8.x86_64.rpm glibc-langpack-miq-2.28-164.el8.x86_64.rpm glibc-langpack-mjw-2.28-164.el8.x86_64.rpm glibc-langpack-mk-2.28-164.el8.x86_64.rpm glibc-langpack-ml-2.28-164.el8.x86_64.rpm glibc-langpack-mn-2.28-164.el8.x86_64.rpm glibc-langpack-mni-2.28-164.el8.x86_64.rpm glibc-langpack-mr-2.28-164.el8.x86_64.rpm glibc-langpack-ms-2.28-164.el8.x86_64.rpm glibc-langpack-mt-2.28-164.el8.x86_64.rpm glibc-langpack-my-2.28-164.el8.x86_64.rpm glibc-langpack-nan-2.28-164.el8.x86_64.rpm glibc-langpack-nb-2.28-164.el8.x86_64.rpm glibc-langpack-nds-2.28-164.el8.x86_64.rpm glibc-langpack-ne-2.28-164.el8.x86_64.rpm glibc-langpack-nhn-2.28-164.el8.x86_64.rpm glibc-langpack-niu-2.28-164.el8.x86_64.rpm glibc-langpack-nl-2.28-164.el8.x86_64.rpm glibc-langpack-nn-2.28-164.el8.x86_64.rpm glibc-langpack-nr-2.28-164.el8.x86_64.rpm glibc-langpack-nso-2.28-164.el8.x86_64.rpm glibc-langpack-oc-2.28-164.el8.x86_64.rpm glibc-langpack-om-2.28-164.el8.x86_64.rpm glibc-langpack-or-2.28-164.el8.x86_64.rpm glibc-langpack-os-2.28-164.el8.x86_64.rpm glibc-langpack-pa-2.28-164.el8.x86_64.rpm glibc-langpack-pap-2.28-164.el8.x86_64.rpm glibc-langpack-pl-2.28-164.el8.x86_64.rpm glibc-langpack-ps-2.28-164.el8.x86_64.rpm glibc-langpack-pt-2.28-164.el8.x86_64.rpm glibc-langpack-quz-2.28-164.el8.x86_64.rpm glibc-langpack-raj-2.28-164.el8.x86_64.rpm glibc-langpack-ro-2.28-164.el8.x86_64.rpm glibc-langpack-ru-2.28-164.el8.x86_64.rpm glibc-langpack-rw-2.28-164.el8.x86_64.rpm glibc-langpack-sa-2.28-164.el8.x86_64.rpm glibc-langpack-sah-2.28-164.el8.x86_64.rpm glibc-langpack-sat-2.28-164.el8.x86_64.rpm glibc-langpack-sc-2.28-164.el8.x86_64.rpm glibc-langpack-sd-2.28-164.el8.x86_64.rpm glibc-langpack-se-2.28-164.el8.x86_64.rpm glibc-langpack-sgs-2.28-164.el8.x86_64.rpm glibc-langpack-shn-2.28-164.el8.x86_64.rpm glibc-langpack-shs-2.28-164.el8.x86_64.rpm glibc-langpack-si-2.28-164.el8.x86_64.rpm glibc-langpack-sid-2.28-164.el8.x86_64.rpm glibc-langpack-sk-2.28-164.el8.x86_64.rpm glibc-langpack-sl-2.28-164.el8.x86_64.rpm glibc-langpack-sm-2.28-164.el8.x86_64.rpm glibc-langpack-so-2.28-164.el8.x86_64.rpm glibc-langpack-sq-2.28-164.el8.x86_64.rpm glibc-langpack-sr-2.28-164.el8.x86_64.rpm glibc-langpack-ss-2.28-164.el8.x86_64.rpm glibc-langpack-st-2.28-164.el8.x86_64.rpm glibc-langpack-sv-2.28-164.el8.x86_64.rpm glibc-langpack-sw-2.28-164.el8.x86_64.rpm glibc-langpack-szl-2.28-164.el8.x86_64.rpm glibc-langpack-ta-2.28-164.el8.x86_64.rpm glibc-langpack-tcy-2.28-164.el8.x86_64.rpm glibc-langpack-te-2.28-164.el8.x86_64.rpm glibc-langpack-tg-2.28-164.el8.x86_64.rpm glibc-langpack-th-2.28-164.el8.x86_64.rpm glibc-langpack-the-2.28-164.el8.x86_64.rpm glibc-langpack-ti-2.28-164.el8.x86_64.rpm glibc-langpack-tig-2.28-164.el8.x86_64.rpm glibc-langpack-tk-2.28-164.el8.x86_64.rpm glibc-langpack-tl-2.28-164.el8.x86_64.rpm glibc-langpack-tn-2.28-164.el8.x86_64.rpm glibc-langpack-to-2.28-164.el8.x86_64.rpm glibc-langpack-tpi-2.28-164.el8.x86_64.rpm glibc-langpack-tr-2.28-164.el8.x86_64.rpm glibc-langpack-ts-2.28-164.el8.x86_64.rpm glibc-langpack-tt-2.28-164.el8.x86_64.rpm glibc-langpack-ug-2.28-164.el8.x86_64.rpm glibc-langpack-uk-2.28-164.el8.x86_64.rpm glibc-langpack-unm-2.28-164.el8.x86_64.rpm glibc-langpack-ur-2.28-164.el8.x86_64.rpm glibc-langpack-uz-2.28-164.el8.x86_64.rpm glibc-langpack-ve-2.28-164.el8.x86_64.rpm glibc-langpack-vi-2.28-164.el8.x86_64.rpm glibc-langpack-wa-2.28-164.el8.x86_64.rpm glibc-langpack-wae-2.28-164.el8.x86_64.rpm glibc-langpack-wal-2.28-164.el8.x86_64.rpm glibc-langpack-wo-2.28-164.el8.x86_64.rpm glibc-langpack-xh-2.28-164.el8.x86_64.rpm glibc-langpack-yi-2.28-164.el8.x86_64.rpm glibc-langpack-yo-2.28-164.el8.x86_64.rpm glibc-langpack-yue-2.28-164.el8.x86_64.rpm glibc-langpack-yuw-2.28-164.el8.x86_64.rpm glibc-langpack-zh-2.28-164.el8.x86_64.rpm glibc-langpack-zu-2.28-164.el8.x86_64.rpm glibc-locale-source-2.28-164.el8.x86_64.rpm glibc-minimal-langpack-2.28-164.el8.x86_64.rpm libnsl-2.28-164.el8.i686.rpm libnsl-2.28-164.el8.x86_64.rpm nscd-2.28-164.el8.x86_64.rpm nss_db-2.28-164.el8.i686.rpm nss_db-2.28-164.el8.x86_64.rpm
Red Hat Enterprise Linux CRB (v. 8):
aarch64: glibc-benchtests-2.28-164.el8.aarch64.rpm glibc-debuginfo-2.28-164.el8.aarch64.rpm glibc-nss-devel-2.28-164.el8.aarch64.rpm glibc-static-2.28-164.el8.aarch64.rpm nss_hesiod-2.28-164.el8.aarch64.rpm
ppc64le: glibc-benchtests-2.28-164.el8.ppc64le.rpm glibc-debuginfo-2.28-164.el8.ppc64le.rpm glibc-debuginfo-common-2.28-164.el8.ppc64le.rpm glibc-nss-devel-2.28-164.el8.ppc64le.rpm glibc-static-2.28-164.el8.ppc64le.rpm nss_hesiod-2.28-164.el8.ppc64le.rpm
s390x: glibc-benchtests-2.28-164.el8.s390x.rpm glibc-debuginfo-2.28-164.el8.s390x.rpm glibc-debuginfo-common-2.28-164.el8.s390x.rpm glibc-nss-devel-2.28-164.el8.s390x.rpm glibc-static-2.28-164.el8.s390x.rpm nss_hesiod-2.28-164.el8.s390x.rpm
x86_64: glibc-benchtests-2.28-164.el8.x86_64.rpm glibc-debuginfo-2.28-164.el8.i686.rpm glibc-debuginfo-2.28-164.el8.x86_64.rpm glibc-debuginfo-common-2.28-164.el8.i686.rpm glibc-debuginfo-common-2.28-164.el8.x86_64.rpm glibc-nss-devel-2.28-164.el8.i686.rpm glibc-nss-devel-2.28-164.el8.x86_64.rpm glibc-static-2.28-164.el8.i686.rpm glibc-static-2.28-164.el8.x86_64.rpm nss_hesiod-2.28-164.el8.i686.rpm nss_hesiod-2.28-164.el8.x86_64.rpm
These packages are GPG signed by Red Hat for security. Our key and details on how to verify the signature are available from https://access.redhat.com/security/team/key/
- References:
https://access.redhat.com/security/cve/CVE-2021-27645 https://access.redhat.com/security/cve/CVE-2021-33574 https://access.redhat.com/security/cve/CVE-2021-35942 https://access.redhat.com/security/updates/classification/#moderate https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/8.5_release_notes/
- Contact:
The Red Hat security contact is secalert@redhat.com. More contact details at https://access.redhat.com/security/team/contact/
Copyright 2021 Red Hat, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iQIVAwUBYYreQ9zjgjWX9erEAQhH6Q//Sbg528iEujRXW+yNO7ZtLCcgn8oDHgiD TvPa6VRcP/E4lByAPC3fGxxrcoXnDbD+vB2Ew/R1l4rAT1WP/WCaqX+gY1b4eVLU HxsZAfg849CCe4k0Bai5MtB/BU6/WEIUD5ACACEhIPfgPoNUONAeZLmNPFRj3Rpj Sk3NmXlG9lkkrfGexwGokGDPsq62pZqwbF+oPkTfCFFvbzrBF/sS8CfkB5Rws8tM aBJXEgpnyJlDJ0FDoQ7yuSVZNfuVbnFcJmAWr8c+eeR46C0aWfl3ETxNbcNCCuUj dTBjthu7ZG/88DuOVQwGIZOyC8HNwhzVIHPK0SVmCJeF3eHULJ1mYwaBqQ6YzwuP TCox0iZMA7vHsGvB0OCJbARfZKeIJTe7T9vqQxOGaOdI5QgttZObgLJub4Y8kjiq 61Mxx5pKumqRy/k0p9SAn0oHbXC9iholWg/TWblj31TJY4FXMLTzJckt96IjYyTq LskhunzwcwE3FtmlYBVc4nDty/+lTnUbMFrxynPng8obd0sRINn/ZEoZF32iLjoB LUs04wy0iG2segTBbbG+Se80NnjABc8Eedy+ksycT1PAt1sWfLfqUO3OFsN+0995 u+mDEbqXullTWozC3o/AUzsDGS/Cf2EFEPjhfcoxecQRqj+jG316CnBRyY0juSK1 qL31MTX7XJI=i/Jb -----END PGP SIGNATURE-----
-- RHSA-announce mailing list RHSA-announce@redhat.com https://listman.redhat.com/mailman/listinfo/rhsa-announce . Description:
Red Hat Advanced Cluster Management for Kubernetes 2.2.10 images
Red Hat Advanced Cluster Management for Kubernetes provides the capabilities to address common challenges that administrators and site reliability engineers face as they work across a range of public and private cloud environments.
Clusters and applications are all visible and managed from a single console — with security policy built in. See the following Release Notes documentation, which will be updated shortly for this release, for additional details about this release:
https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.2/html/release_notes/
Security fixes:
-
CVE-2021-3795 semver-regex: inefficient regular expression complexity
-
CVE-2021-23440 nodejs-set-value: type confusion allows bypass of CVE-2019-10747
Related bugs:
-
RHACM 2.2.10 images (Bugzilla #2013652)
-
Bugs fixed (https://bugzilla.redhat.com/):
2004944 - CVE-2021-23440 nodejs-set-value: type confusion allows bypass of CVE-2019-10747 2006009 - CVE-2021-3795 semver-regex: inefficient regular expression complexity 2013652 - RHACM 2.2.10 images
- Bugs fixed (https://bugzilla.redhat.com/):
1963232 - CVE-2021-33194 golang: x/net/html: infinite loop in ParseFragment
- JIRA issues fixed (https://issues.jboss.org/):
LOG-1168 - Disable hostname verification in syslog TLS settings
LOG-1235 - Using HTTPS without a secret does not translate into the correct 'scheme' value in Fluentd
LOG-1375 - ssl_ca_cert should be optional
LOG-1378 - CLO should support sasl_plaintext(Password over http)
LOG-1392 - In fluentd config, flush_interval can't be set with flush_mode=immediate
LOG-1494 - Syslog output is serializing json incorrectly
LOG-1555 - Fluentd logs emit transaction failed: error_class=NoMethodError while forwarding to external syslog server
LOG-1575 - Rejected by Elasticsearch and unexpected json-parsing
LOG-1735 - Regression introducing flush_at_shutdown
LOG-1774 - The collector logs should be excluded in fluent.conf
LOG-1776 - fluentd total_limit_size sets value beyond available space
LOG-1822 - OpenShift Alerting Rules Style-Guide Compliance
LOG-1859 - CLO Should not error and exit early on missing ca-bundle when cluster wide proxy is not enabled
LOG-1862 - Unsupported kafka parameters when enabled Kafka SASL
LOG-1903 - Fix the Display of ClusterLogging type in OLM
LOG-1911 - CLF API changes to Opt-in to multiline error detection
LOG-1918 - Alert FluentdNodeDown
always firing
LOG-1939 - Opt-in multiline detection breaks cloudwatch forwarding
- Description:
Red Hat OpenShift Container Storage is software-defined storage integrated with and optimized for the Red Hat OpenShift Container Platform. Red Hat OpenShift Container Storage is highly scalable, production-grade persistent storage for stateful applications running in the Red Hat OpenShift Container Platform. In addition to persistent storage, Red Hat OpenShift Container Storage provides a multicloud data management service with an S3 compatible API.
Bug Fix(es):
-
Previously, when the namespace store target was deleted, no alert was sent to the namespace bucket because of an issue in calculating the namespace bucket health. With this update, the issue in calculating the namespace bucket health is fixed and alerts are triggered as expected. (BZ#1993873)
-
Previously, the Multicloud Object Gateway (MCG) components performed slowly and there was a lot of pressure on the MCG components due to non-optimized database queries. With this update the non-optimized database queries are fixed which reduces the compute resources and time taken for queries. Bugs fixed (https://bugzilla.redhat.com/):
1993873 - [4.8.z clone] Alert NooBaaNamespaceBucketErrorState is not triggered when namespacestore's target bucket is deleted 2006958 - CVE-2020-26301 nodejs-ssh2: Command injection by calling vulnerable method with untrusted input
5
Show details on source website{ "@context": { "@vocab": "https://www.variotdbs.pl/ref/VARIoTentry#", "affected_products": { "@id": "https://www.variotdbs.pl/ref/affected_products" }, "credits": { "@id": "https://www.variotdbs.pl/ref/credits" }, "cvss": { "@id": "https://www.variotdbs.pl/ref/cvss/" }, "description": { "@id": "https://www.variotdbs.pl/ref/description/" }, "exploit_availability": { "@id": "https://www.variotdbs.pl/ref/exploit_availability/" }, "external_ids": { "@id": "https://www.variotdbs.pl/ref/external_ids/" }, "iot": { "@id": "https://www.variotdbs.pl/ref/iot/" }, "patch": { "@id": "https://www.variotdbs.pl/ref/patch/" }, "problemtype_data": { "@id": "https://www.variotdbs.pl/ref/problemtype_data/" }, "references": { "@id": "https://www.variotdbs.pl/ref/references/" }, "sources": { "@id": "https://www.variotdbs.pl/ref/sources/" }, "sources_release_date": { "@id": "https://www.variotdbs.pl/ref/sources_release_date/" }, "sources_update_date": { "@id": "https://www.variotdbs.pl/ref/sources_update_date/" }, "threat_type": { "@id": "https://www.variotdbs.pl/ref/threat_type/" }, "title": { "@id": "https://www.variotdbs.pl/ref/title/" }, "type": { "@id": "https://www.variotdbs.pl/ref/type/" } }, "@id": "https://www.variotdbs.pl/vuln/VAR-202105-1306", "affected_products": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/affected_products#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" }, "@id": "https://www.variotdbs.pl/ref/sources" } }, "data": [ { "model": "h700e", "scope": "eq", "trust": 1.0, "vendor": "netapp", "version": null }, { "model": "fedora", "scope": "eq", "trust": 1.0, "vendor": "fedoraproject", "version": "34" }, { "model": "e-series santricity os controller", "scope": "gte", "trust": 1.0, "vendor": "netapp", "version": "11.0" }, { "model": "e-series santricity os controller", "scope": "lte", "trust": 1.0, "vendor": "netapp", "version": "11.70.1" }, { "model": "h500e", "scope": "eq", "trust": 1.0, "vendor": "netapp", "version": null }, { "model": "h300e", "scope": "eq", "trust": 1.0, "vendor": "netapp", "version": null }, { "model": "cloud backup", "scope": "eq", "trust": 1.0, "vendor": "netapp", "version": null }, { "model": "h300s", "scope": "eq", "trust": 1.0, "vendor": "netapp", "version": null }, { "model": "h410s", "scope": "eq", "trust": 1.0, "vendor": "netapp", "version": null }, { "model": "glibc", "scope": "eq", "trust": 1.0, "vendor": "gnu", "version": "2.32" }, { "model": "h500s", "scope": "eq", "trust": 1.0, "vendor": "netapp", "version": null }, { "model": "h700s", "scope": "eq", "trust": 1.0, "vendor": "netapp", "version": null }, { "model": "linux", "scope": "eq", "trust": 1.0, "vendor": "debian", "version": "10.0" }, { "model": "glibc", "scope": "eq", "trust": 1.0, "vendor": "gnu", "version": "2.33" }, { "model": "solidfire baseboard management controller", "scope": "eq", "trust": 1.0, "vendor": "netapp", "version": null }, { "model": "fedora", "scope": "eq", "trust": 1.0, "vendor": "fedoraproject", "version": "33" }, { "model": "c library", "scope": "eq", "trust": 0.8, "vendor": "gnu", "version": "2.32" }, { "model": "c library", "scope": "eq", "trust": 0.8, "vendor": "gnu", "version": null }, { "model": "c library", "scope": "eq", "trust": 0.8, "vendor": "gnu", "version": "2.33" } ], "sources": [ { "db": "JVNDB", "id": "JVNDB-2021-002276" }, { "db": "NVD", "id": "CVE-2021-33574" } ] }, "credits": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/credits#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "Red Hat", "sources": [ { "db": "PACKETSTORM", "id": "165296" }, { "db": "PACKETSTORM", "id": "165286" }, { "db": "PACKETSTORM", "id": "165287" }, { "db": "PACKETSTORM", "id": "164863" }, { "db": "PACKETSTORM", "id": "165209" }, { "db": "PACKETSTORM", "id": "164967" }, { "db": "PACKETSTORM", "id": "165096" } ], "trust": 0.7 }, "cve": "CVE-2021-33574", "cvss": { "@context": { "cvssV2": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/cvss/cvssV2#" }, "@id": "https://www.variotdbs.pl/ref/cvss/cvssV2" }, "cvssV3": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/cvss/cvssV3#" }, "@id": "https://www.variotdbs.pl/ref/cvss/cvssV3/" }, "severity": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/cvss/severity#" }, "@id": "https://www.variotdbs.pl/ref/cvss/severity" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" }, "@id": "https://www.variotdbs.pl/ref/sources" } }, "data": [ { "cvssV2": [ { "accessComplexity": "LOW", "accessVector": "NETWORK", "authentication": "NONE", "author": "nvd@nist.gov", "availabilityImpact": "PARTIAL", "baseScore": 7.5, "confidentialityImpact": "PARTIAL", "exploitabilityScore": 10.0, "id": "CVE-2021-33574", "impactScore": 6.4, "integrityImpact": "PARTIAL", "severity": "HIGH", "trust": 1.9, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0" }, { "accessComplexity": "LOW", "accessVector": "NETWORK", "authentication": "NONE", "author": "VULHUB", "availabilityImpact": "PARTIAL", "baseScore": 7.5, "confidentialityImpact": "PARTIAL", "exploitabilityScore": 10.0, "id": "VHN-393646", "impactScore": 6.4, "integrityImpact": "PARTIAL", "severity": "HIGH", "trust": 0.1, "vectorString": "AV:N/AC:L/AU:N/C:P/I:P/A:P", "version": "2.0" } ], "cvssV3": [ { "attackComplexity": "LOW", "attackVector": "NETWORK", "author": "nvd@nist.gov", "availabilityImpact": "HIGH", "baseScore": 9.8, "baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "exploitabilityScore": 3.9, "id": "CVE-2021-33574", "impactScore": 5.9, "integrityImpact": "HIGH", "privilegesRequired": "NONE", "scope": "UNCHANGED", "trust": 1.0, "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1" }, { "attackComplexity": "Low", "attackVector": "Network", "author": "NVD", "availabilityImpact": "High", "baseScore": 9.8, "baseSeverity": "Critical", "confidentialityImpact": "High", "exploitabilityScore": null, "id": "CVE-2021-33574", "impactScore": null, "integrityImpact": "High", "privilegesRequired": "None", "scope": "Unchanged", "trust": 0.8, "userInteraction": "None", "vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.0" } ], "severity": [ { "author": "nvd@nist.gov", "id": "CVE-2021-33574", "trust": 1.0, "value": "CRITICAL" }, { "author": "NVD", "id": "CVE-2021-33574", "trust": 0.8, "value": "Critical" }, { "author": "CNNVD", "id": "CNNVD-202105-1666", "trust": 0.6, "value": "CRITICAL" }, { "author": "VULHUB", "id": "VHN-393646", "trust": 0.1, "value": "HIGH" }, { "author": "VULMON", "id": "CVE-2021-33574", "trust": 0.1, "value": "HIGH" } ] } ], "sources": [ { "db": "VULHUB", "id": "VHN-393646" }, { "db": "VULMON", "id": "CVE-2021-33574" }, { "db": "JVNDB", "id": "JVNDB-2021-002276" }, { "db": "CNNVD", "id": "CNNVD-202105-1666" }, { "db": "NVD", "id": "CVE-2021-33574" } ] }, "description": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/description#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "The mq_notify function in the GNU C Library (aka glibc) versions 2.32 and 2.33 has a use-after-free. It may use the notification thread attributes object (passed through its struct sigevent parameter) after it has been freed by the caller, leading to a denial of service (application crash) or possibly unspecified other impact. GNU C Library ( alias glibc) Is vulnerable to the use of freed memory.Information is obtained, information is tampered with, and service is disrupted (DoS) It may be put into a state. The vulnerability stems from the library\u0027s mq_notify function having a use-after-free feature. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\nGentoo Linux Security Advisory GLSA 202107-07\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n https://security.gentoo.org/\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n\n Severity: Normal\n Title: glibc: Multiple vulnerabilities\n Date: July 06, 2021\n Bugs: #764176, #767718, #772425, #792261\n ID: 202107-07\n\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n\nSynopsis\n========\n\nMultiple vulnerabilities in glibc could result in Denial of Service. \n\nAffected packages\n=================\n\n -------------------------------------------------------------------\n Package / Vulnerable / Unaffected\n -------------------------------------------------------------------\n 1 sys-libs/glibc \u003c 2.33-r1 \u003e= 2.33-r1 \n\nDescription\n===========\n\nMultiple vulnerabilities have been discovered in glibc. Please review\nthe CVE identifiers referenced below for details. \n\nImpact\n======\n\nAn attacker could cause a possible Denial of Service condition. \n\nWorkaround\n==========\n\nThere is no known workaround at this time. \n\nResolution\n==========\n\nAll glibc users should upgrade to the latest version:\n\n # emerge --sync\n # emerge --ask --oneshot --verbose \"\u003e=sys-libs/glibc-2.33-r1\"\n\nReferences\n==========\n\n[ 1 ] CVE-2019-25013\n https://nvd.nist.gov/vuln/detail/CVE-2019-25013\n[ 2 ] CVE-2020-27618\n https://nvd.nist.gov/vuln/detail/CVE-2020-27618\n[ 3 ] CVE-2021-27645\n https://nvd.nist.gov/vuln/detail/CVE-2021-27645\n[ 4 ] CVE-2021-3326\n https://nvd.nist.gov/vuln/detail/CVE-2021-3326\n[ 5 ] CVE-2021-33574\n https://nvd.nist.gov/vuln/detail/CVE-2021-33574\n\nAvailability\n============\n\nThis GLSA and any updates to it are available for viewing at\nthe Gentoo Security Website:\n\n https://security.gentoo.org/glsa/202107-07\n\nConcerns?\n=========\n\nSecurity is a primary focus of Gentoo Linux and ensuring the\nconfidentiality and security of our users\u0027 machines is of utmost\nimportance to us. Any security concerns should be addressed to\nsecurity@gentoo.org or alternatively, you may file a bug at\nhttps://bugs.gentoo.org. \n\nLicense\n=======\n\nCopyright 2021 Gentoo Foundation, Inc; referenced text\nbelongs to its owner(s). \n\nThe contents of this document are licensed under the\nCreative Commons - Attribution / Share Alike license. \n\nhttps://creativecommons.org/licenses/by-sa/2.5\n\n. Bugs fixed (https://bugzilla.redhat.com/):\n\n1944888 - CVE-2021-21409 netty: Request smuggling via content-length header\n2004133 - CVE-2021-37136 netty-codec: Bzip2Decoder doesn\u0027t allow setting size restrictions for decompressed data\n2004135 - CVE-2021-37137 netty-codec: SnappyFrameDecoder doesn\u0027t restrict chunk length and may buffer skippable chunks in an unnecessary way\n2030932 - CVE-2021-44228 log4j-core: Remote code execution in Log4j 2.x when logs contain an attacker-controlled string value\n\n5. JIRA issues fixed (https://issues.jboss.org/):\n\nLOG-1971 - Applying cluster state is causing elasticsearch to hit an issue and become unusable\n\n6. -----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\n==================================================================== \nRed Hat Security Advisory\n\nSynopsis: Moderate: glibc security, bug fix, and enhancement update\nAdvisory ID: RHSA-2021:4358-01\nProduct: Red Hat Enterprise Linux\nAdvisory URL: https://access.redhat.com/errata/RHSA-2021:4358\nIssue date: 2021-11-09\nCVE Names: CVE-2021-27645 CVE-2021-33574 CVE-2021-35942\n====================================================================\n1. Summary:\n\nAn update for glibc is now available for Red Hat Enterprise Linux 8. \n\nRed Hat Product Security has rated this update as having a security impact\nof Moderate. A Common Vulnerability Scoring System (CVSS) base score, which\ngives a detailed severity rating, is available for each vulnerability from\nthe CVE link(s) in the References section. \n\n2. Relevant releases/architectures:\n\nRed Hat Enterprise Linux AppStream (v. 8) - aarch64, ppc64le, s390x, x86_64\nRed Hat Enterprise Linux BaseOS (v. 8) - aarch64, ppc64le, s390x, x86_64\nRed Hat Enterprise Linux CRB (v. 8) - aarch64, ppc64le, s390x, x86_64\n\n3. Description:\n\nThe glibc packages provide the standard C libraries (libc), POSIX thread\nlibraries (libpthread), standard math libraries (libm), and the name\nservice cache daemon (nscd) used by multiple programs on the system. \nWithout these libraries, the Linux system cannot function correctly. \n\nSecurity Fix(es):\n\n* glibc: Arbitrary read in wordexp() (CVE-2021-35942)\n\n* glibc: Use-after-free in addgetnetgrentX function in netgroupcache.c\n(CVE-2021-27645)\n\n* glibc: mq_notify does not handle separately allocated thread attributes\n(CVE-2021-33574)\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\nAdditional Changes:\n\nFor detailed information on changes in this release, see the Red Hat\nEnterprise Linux 8.5 Release Notes linked from the References section. \n\n4. Solution:\n\nFor details on how to apply this update, which includes the changes\ndescribed in this advisory, refer to:\n\nhttps://access.redhat.com/articles/11258\n\nFor the update to take effect, all services linked to the glibc library\nmust be restarted, or the system rebooted. \n\n5. Bugs fixed (https://bugzilla.redhat.com/):\n\n1871386 - glibc: Update syscall names for Linux 5.6, 5.7, and 5.8. \n1912670 - semctl SEM_STAT_ANY fails to pass the buffer specified by the caller to the kernel\n1927877 - CVE-2021-27645 glibc: Use-after-free in addgetnetgrentX function in netgroupcache.c [rhel-8]\n1930302 - glibc: provide IPPROTO_MPTCP definition\n1932589 - CVE-2021-27645 glibc: Use-after-free in addgetnetgrentX function in netgroupcache.c\n1935128 - glibc: Rebuild glibc after objcopy fix for bug 1928936 [rhel-8.5.0]\n1965408 - CVE-2021-33574 glibc: mq_notify does not handle separately allocated thread attributes\n1977975 - CVE-2021-35942 glibc: Arbitrary read in wordexp()\n\n6. Package List:\n\nRed Hat Enterprise Linux AppStream (v. 8):\n\naarch64:\ncompat-libpthread-nonshared-2.28-164.el8.aarch64.rpm\nglibc-debuginfo-2.28-164.el8.aarch64.rpm\nglibc-utils-2.28-164.el8.aarch64.rpm\n\nppc64le:\ncompat-libpthread-nonshared-2.28-164.el8.ppc64le.rpm\nglibc-debuginfo-2.28-164.el8.ppc64le.rpm\nglibc-debuginfo-common-2.28-164.el8.ppc64le.rpm\nglibc-utils-2.28-164.el8.ppc64le.rpm\n\ns390x:\ncompat-libpthread-nonshared-2.28-164.el8.s390x.rpm\nglibc-debuginfo-2.28-164.el8.s390x.rpm\nglibc-debuginfo-common-2.28-164.el8.s390x.rpm\nglibc-utils-2.28-164.el8.s390x.rpm\n\nx86_64:\ncompat-libpthread-nonshared-2.28-164.el8.x86_64.rpm\nglibc-debuginfo-2.28-164.el8.x86_64.rpm\nglibc-debuginfo-common-2.28-164.el8.x86_64.rpm\nglibc-utils-2.28-164.el8.x86_64.rpm\n\nRed Hat Enterprise Linux BaseOS (v. 8):\n\nSource:\nglibc-2.28-164.el8.src.rpm\n\naarch64:\nglibc-2.28-164.el8.aarch64.rpm\nglibc-all-langpacks-2.28-164.el8.aarch64.rpm\nglibc-common-2.28-164.el8.aarch64.rpm\nglibc-debuginfo-2.28-164.el8.aarch64.rpm\nglibc-devel-2.28-164.el8.aarch64.rpm\nglibc-headers-2.28-164.el8.aarch64.rpm\nglibc-langpack-aa-2.28-164.el8.aarch64.rpm\nglibc-langpack-af-2.28-164.el8.aarch64.rpm\nglibc-langpack-agr-2.28-164.el8.aarch64.rpm\nglibc-langpack-ak-2.28-164.el8.aarch64.rpm\nglibc-langpack-am-2.28-164.el8.aarch64.rpm\nglibc-langpack-an-2.28-164.el8.aarch64.rpm\nglibc-langpack-anp-2.28-164.el8.aarch64.rpm\nglibc-langpack-ar-2.28-164.el8.aarch64.rpm\nglibc-langpack-as-2.28-164.el8.aarch64.rpm\nglibc-langpack-ast-2.28-164.el8.aarch64.rpm\nglibc-langpack-ayc-2.28-164.el8.aarch64.rpm\nglibc-langpack-az-2.28-164.el8.aarch64.rpm\nglibc-langpack-be-2.28-164.el8.aarch64.rpm\nglibc-langpack-bem-2.28-164.el8.aarch64.rpm\nglibc-langpack-ber-2.28-164.el8.aarch64.rpm\nglibc-langpack-bg-2.28-164.el8.aarch64.rpm\nglibc-langpack-bhb-2.28-164.el8.aarch64.rpm\nglibc-langpack-bho-2.28-164.el8.aarch64.rpm\nglibc-langpack-bi-2.28-164.el8.aarch64.rpm\nglibc-langpack-bn-2.28-164.el8.aarch64.rpm\nglibc-langpack-bo-2.28-164.el8.aarch64.rpm\nglibc-langpack-br-2.28-164.el8.aarch64.rpm\nglibc-langpack-brx-2.28-164.el8.aarch64.rpm\nglibc-langpack-bs-2.28-164.el8.aarch64.rpm\nglibc-langpack-byn-2.28-164.el8.aarch64.rpm\nglibc-langpack-ca-2.28-164.el8.aarch64.rpm\nglibc-langpack-ce-2.28-164.el8.aarch64.rpm\nglibc-langpack-chr-2.28-164.el8.aarch64.rpm\nglibc-langpack-cmn-2.28-164.el8.aarch64.rpm\nglibc-langpack-crh-2.28-164.el8.aarch64.rpm\nglibc-langpack-cs-2.28-164.el8.aarch64.rpm\nglibc-langpack-csb-2.28-164.el8.aarch64.rpm\nglibc-langpack-cv-2.28-164.el8.aarch64.rpm\nglibc-langpack-cy-2.28-164.el8.aarch64.rpm\nglibc-langpack-da-2.28-164.el8.aarch64.rpm\nglibc-langpack-de-2.28-164.el8.aarch64.rpm\nglibc-langpack-doi-2.28-164.el8.aarch64.rpm\nglibc-langpack-dsb-2.28-164.el8.aarch64.rpm\nglibc-langpack-dv-2.28-164.el8.aarch64.rpm\nglibc-langpack-dz-2.28-164.el8.aarch64.rpm\nglibc-langpack-el-2.28-164.el8.aarch64.rpm\nglibc-langpack-en-2.28-164.el8.aarch64.rpm\nglibc-langpack-eo-2.28-164.el8.aarch64.rpm\nglibc-langpack-es-2.28-164.el8.aarch64.rpm\nglibc-langpack-et-2.28-164.el8.aarch64.rpm\nglibc-langpack-eu-2.28-164.el8.aarch64.rpm\nglibc-langpack-fa-2.28-164.el8.aarch64.rpm\nglibc-langpack-ff-2.28-164.el8.aarch64.rpm\nglibc-langpack-fi-2.28-164.el8.aarch64.rpm\nglibc-langpack-fil-2.28-164.el8.aarch64.rpm\nglibc-langpack-fo-2.28-164.el8.aarch64.rpm\nglibc-langpack-fr-2.28-164.el8.aarch64.rpm\nglibc-langpack-fur-2.28-164.el8.aarch64.rpm\nglibc-langpack-fy-2.28-164.el8.aarch64.rpm\nglibc-langpack-ga-2.28-164.el8.aarch64.rpm\nglibc-langpack-gd-2.28-164.el8.aarch64.rpm\nglibc-langpack-gez-2.28-164.el8.aarch64.rpm\nglibc-langpack-gl-2.28-164.el8.aarch64.rpm\nglibc-langpack-gu-2.28-164.el8.aarch64.rpm\nglibc-langpack-gv-2.28-164.el8.aarch64.rpm\nglibc-langpack-ha-2.28-164.el8.aarch64.rpm\nglibc-langpack-hak-2.28-164.el8.aarch64.rpm\nglibc-langpack-he-2.28-164.el8.aarch64.rpm\nglibc-langpack-hi-2.28-164.el8.aarch64.rpm\nglibc-langpack-hif-2.28-164.el8.aarch64.rpm\nglibc-langpack-hne-2.28-164.el8.aarch64.rpm\nglibc-langpack-hr-2.28-164.el8.aarch64.rpm\nglibc-langpack-hsb-2.28-164.el8.aarch64.rpm\nglibc-langpack-ht-2.28-164.el8.aarch64.rpm\nglibc-langpack-hu-2.28-164.el8.aarch64.rpm\nglibc-langpack-hy-2.28-164.el8.aarch64.rpm\nglibc-langpack-ia-2.28-164.el8.aarch64.rpm\nglibc-langpack-id-2.28-164.el8.aarch64.rpm\nglibc-langpack-ig-2.28-164.el8.aarch64.rpm\nglibc-langpack-ik-2.28-164.el8.aarch64.rpm\nglibc-langpack-is-2.28-164.el8.aarch64.rpm\nglibc-langpack-it-2.28-164.el8.aarch64.rpm\nglibc-langpack-iu-2.28-164.el8.aarch64.rpm\nglibc-langpack-ja-2.28-164.el8.aarch64.rpm\nglibc-langpack-ka-2.28-164.el8.aarch64.rpm\nglibc-langpack-kab-2.28-164.el8.aarch64.rpm\nglibc-langpack-kk-2.28-164.el8.aarch64.rpm\nglibc-langpack-kl-2.28-164.el8.aarch64.rpm\nglibc-langpack-km-2.28-164.el8.aarch64.rpm\nglibc-langpack-kn-2.28-164.el8.aarch64.rpm\nglibc-langpack-ko-2.28-164.el8.aarch64.rpm\nglibc-langpack-kok-2.28-164.el8.aarch64.rpm\nglibc-langpack-ks-2.28-164.el8.aarch64.rpm\nglibc-langpack-ku-2.28-164.el8.aarch64.rpm\nglibc-langpack-kw-2.28-164.el8.aarch64.rpm\nglibc-langpack-ky-2.28-164.el8.aarch64.rpm\nglibc-langpack-lb-2.28-164.el8.aarch64.rpm\nglibc-langpack-lg-2.28-164.el8.aarch64.rpm\nglibc-langpack-li-2.28-164.el8.aarch64.rpm\nglibc-langpack-lij-2.28-164.el8.aarch64.rpm\nglibc-langpack-ln-2.28-164.el8.aarch64.rpm\nglibc-langpack-lo-2.28-164.el8.aarch64.rpm\nglibc-langpack-lt-2.28-164.el8.aarch64.rpm\nglibc-langpack-lv-2.28-164.el8.aarch64.rpm\nglibc-langpack-lzh-2.28-164.el8.aarch64.rpm\nglibc-langpack-mag-2.28-164.el8.aarch64.rpm\nglibc-langpack-mai-2.28-164.el8.aarch64.rpm\nglibc-langpack-mfe-2.28-164.el8.aarch64.rpm\nglibc-langpack-mg-2.28-164.el8.aarch64.rpm\nglibc-langpack-mhr-2.28-164.el8.aarch64.rpm\nglibc-langpack-mi-2.28-164.el8.aarch64.rpm\nglibc-langpack-miq-2.28-164.el8.aarch64.rpm\nglibc-langpack-mjw-2.28-164.el8.aarch64.rpm\nglibc-langpack-mk-2.28-164.el8.aarch64.rpm\nglibc-langpack-ml-2.28-164.el8.aarch64.rpm\nglibc-langpack-mn-2.28-164.el8.aarch64.rpm\nglibc-langpack-mni-2.28-164.el8.aarch64.rpm\nglibc-langpack-mr-2.28-164.el8.aarch64.rpm\nglibc-langpack-ms-2.28-164.el8.aarch64.rpm\nglibc-langpack-mt-2.28-164.el8.aarch64.rpm\nglibc-langpack-my-2.28-164.el8.aarch64.rpm\nglibc-langpack-nan-2.28-164.el8.aarch64.rpm\nglibc-langpack-nb-2.28-164.el8.aarch64.rpm\nglibc-langpack-nds-2.28-164.el8.aarch64.rpm\nglibc-langpack-ne-2.28-164.el8.aarch64.rpm\nglibc-langpack-nhn-2.28-164.el8.aarch64.rpm\nglibc-langpack-niu-2.28-164.el8.aarch64.rpm\nglibc-langpack-nl-2.28-164.el8.aarch64.rpm\nglibc-langpack-nn-2.28-164.el8.aarch64.rpm\nglibc-langpack-nr-2.28-164.el8.aarch64.rpm\nglibc-langpack-nso-2.28-164.el8.aarch64.rpm\nglibc-langpack-oc-2.28-164.el8.aarch64.rpm\nglibc-langpack-om-2.28-164.el8.aarch64.rpm\nglibc-langpack-or-2.28-164.el8.aarch64.rpm\nglibc-langpack-os-2.28-164.el8.aarch64.rpm\nglibc-langpack-pa-2.28-164.el8.aarch64.rpm\nglibc-langpack-pap-2.28-164.el8.aarch64.rpm\nglibc-langpack-pl-2.28-164.el8.aarch64.rpm\nglibc-langpack-ps-2.28-164.el8.aarch64.rpm\nglibc-langpack-pt-2.28-164.el8.aarch64.rpm\nglibc-langpack-quz-2.28-164.el8.aarch64.rpm\nglibc-langpack-raj-2.28-164.el8.aarch64.rpm\nglibc-langpack-ro-2.28-164.el8.aarch64.rpm\nglibc-langpack-ru-2.28-164.el8.aarch64.rpm\nglibc-langpack-rw-2.28-164.el8.aarch64.rpm\nglibc-langpack-sa-2.28-164.el8.aarch64.rpm\nglibc-langpack-sah-2.28-164.el8.aarch64.rpm\nglibc-langpack-sat-2.28-164.el8.aarch64.rpm\nglibc-langpack-sc-2.28-164.el8.aarch64.rpm\nglibc-langpack-sd-2.28-164.el8.aarch64.rpm\nglibc-langpack-se-2.28-164.el8.aarch64.rpm\nglibc-langpack-sgs-2.28-164.el8.aarch64.rpm\nglibc-langpack-shn-2.28-164.el8.aarch64.rpm\nglibc-langpack-shs-2.28-164.el8.aarch64.rpm\nglibc-langpack-si-2.28-164.el8.aarch64.rpm\nglibc-langpack-sid-2.28-164.el8.aarch64.rpm\nglibc-langpack-sk-2.28-164.el8.aarch64.rpm\nglibc-langpack-sl-2.28-164.el8.aarch64.rpm\nglibc-langpack-sm-2.28-164.el8.aarch64.rpm\nglibc-langpack-so-2.28-164.el8.aarch64.rpm\nglibc-langpack-sq-2.28-164.el8.aarch64.rpm\nglibc-langpack-sr-2.28-164.el8.aarch64.rpm\nglibc-langpack-ss-2.28-164.el8.aarch64.rpm\nglibc-langpack-st-2.28-164.el8.aarch64.rpm\nglibc-langpack-sv-2.28-164.el8.aarch64.rpm\nglibc-langpack-sw-2.28-164.el8.aarch64.rpm\nglibc-langpack-szl-2.28-164.el8.aarch64.rpm\nglibc-langpack-ta-2.28-164.el8.aarch64.rpm\nglibc-langpack-tcy-2.28-164.el8.aarch64.rpm\nglibc-langpack-te-2.28-164.el8.aarch64.rpm\nglibc-langpack-tg-2.28-164.el8.aarch64.rpm\nglibc-langpack-th-2.28-164.el8.aarch64.rpm\nglibc-langpack-the-2.28-164.el8.aarch64.rpm\nglibc-langpack-ti-2.28-164.el8.aarch64.rpm\nglibc-langpack-tig-2.28-164.el8.aarch64.rpm\nglibc-langpack-tk-2.28-164.el8.aarch64.rpm\nglibc-langpack-tl-2.28-164.el8.aarch64.rpm\nglibc-langpack-tn-2.28-164.el8.aarch64.rpm\nglibc-langpack-to-2.28-164.el8.aarch64.rpm\nglibc-langpack-tpi-2.28-164.el8.aarch64.rpm\nglibc-langpack-tr-2.28-164.el8.aarch64.rpm\nglibc-langpack-ts-2.28-164.el8.aarch64.rpm\nglibc-langpack-tt-2.28-164.el8.aarch64.rpm\nglibc-langpack-ug-2.28-164.el8.aarch64.rpm\nglibc-langpack-uk-2.28-164.el8.aarch64.rpm\nglibc-langpack-unm-2.28-164.el8.aarch64.rpm\nglibc-langpack-ur-2.28-164.el8.aarch64.rpm\nglibc-langpack-uz-2.28-164.el8.aarch64.rpm\nglibc-langpack-ve-2.28-164.el8.aarch64.rpm\nglibc-langpack-vi-2.28-164.el8.aarch64.rpm\nglibc-langpack-wa-2.28-164.el8.aarch64.rpm\nglibc-langpack-wae-2.28-164.el8.aarch64.rpm\nglibc-langpack-wal-2.28-164.el8.aarch64.rpm\nglibc-langpack-wo-2.28-164.el8.aarch64.rpm\nglibc-langpack-xh-2.28-164.el8.aarch64.rpm\nglibc-langpack-yi-2.28-164.el8.aarch64.rpm\nglibc-langpack-yo-2.28-164.el8.aarch64.rpm\nglibc-langpack-yue-2.28-164.el8.aarch64.rpm\nglibc-langpack-yuw-2.28-164.el8.aarch64.rpm\nglibc-langpack-zh-2.28-164.el8.aarch64.rpm\nglibc-langpack-zu-2.28-164.el8.aarch64.rpm\nglibc-locale-source-2.28-164.el8.aarch64.rpm\nglibc-minimal-langpack-2.28-164.el8.aarch64.rpm\nlibnsl-2.28-164.el8.aarch64.rpm\nnscd-2.28-164.el8.aarch64.rpm\nnss_db-2.28-164.el8.aarch64.rpm\n\nppc64le:\nglibc-2.28-164.el8.ppc64le.rpm\nglibc-all-langpacks-2.28-164.el8.ppc64le.rpm\nglibc-common-2.28-164.el8.ppc64le.rpm\nglibc-debuginfo-2.28-164.el8.ppc64le.rpm\nglibc-debuginfo-common-2.28-164.el8.ppc64le.rpm\nglibc-devel-2.28-164.el8.ppc64le.rpm\nglibc-headers-2.28-164.el8.ppc64le.rpm\nglibc-langpack-aa-2.28-164.el8.ppc64le.rpm\nglibc-langpack-af-2.28-164.el8.ppc64le.rpm\nglibc-langpack-agr-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ak-2.28-164.el8.ppc64le.rpm\nglibc-langpack-am-2.28-164.el8.ppc64le.rpm\nglibc-langpack-an-2.28-164.el8.ppc64le.rpm\nglibc-langpack-anp-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ar-2.28-164.el8.ppc64le.rpm\nglibc-langpack-as-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ast-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ayc-2.28-164.el8.ppc64le.rpm\nglibc-langpack-az-2.28-164.el8.ppc64le.rpm\nglibc-langpack-be-2.28-164.el8.ppc64le.rpm\nglibc-langpack-bem-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ber-2.28-164.el8.ppc64le.rpm\nglibc-langpack-bg-2.28-164.el8.ppc64le.rpm\nglibc-langpack-bhb-2.28-164.el8.ppc64le.rpm\nglibc-langpack-bho-2.28-164.el8.ppc64le.rpm\nglibc-langpack-bi-2.28-164.el8.ppc64le.rpm\nglibc-langpack-bn-2.28-164.el8.ppc64le.rpm\nglibc-langpack-bo-2.28-164.el8.ppc64le.rpm\nglibc-langpack-br-2.28-164.el8.ppc64le.rpm\nglibc-langpack-brx-2.28-164.el8.ppc64le.rpm\nglibc-langpack-bs-2.28-164.el8.ppc64le.rpm\nglibc-langpack-byn-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ca-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ce-2.28-164.el8.ppc64le.rpm\nglibc-langpack-chr-2.28-164.el8.ppc64le.rpm\nglibc-langpack-cmn-2.28-164.el8.ppc64le.rpm\nglibc-langpack-crh-2.28-164.el8.ppc64le.rpm\nglibc-langpack-cs-2.28-164.el8.ppc64le.rpm\nglibc-langpack-csb-2.28-164.el8.ppc64le.rpm\nglibc-langpack-cv-2.28-164.el8.ppc64le.rpm\nglibc-langpack-cy-2.28-164.el8.ppc64le.rpm\nglibc-langpack-da-2.28-164.el8.ppc64le.rpm\nglibc-langpack-de-2.28-164.el8.ppc64le.rpm\nglibc-langpack-doi-2.28-164.el8.ppc64le.rpm\nglibc-langpack-dsb-2.28-164.el8.ppc64le.rpm\nglibc-langpack-dv-2.28-164.el8.ppc64le.rpm\nglibc-langpack-dz-2.28-164.el8.ppc64le.rpm\nglibc-langpack-el-2.28-164.el8.ppc64le.rpm\nglibc-langpack-en-2.28-164.el8.ppc64le.rpm\nglibc-langpack-eo-2.28-164.el8.ppc64le.rpm\nglibc-langpack-es-2.28-164.el8.ppc64le.rpm\nglibc-langpack-et-2.28-164.el8.ppc64le.rpm\nglibc-langpack-eu-2.28-164.el8.ppc64le.rpm\nglibc-langpack-fa-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ff-2.28-164.el8.ppc64le.rpm\nglibc-langpack-fi-2.28-164.el8.ppc64le.rpm\nglibc-langpack-fil-2.28-164.el8.ppc64le.rpm\nglibc-langpack-fo-2.28-164.el8.ppc64le.rpm\nglibc-langpack-fr-2.28-164.el8.ppc64le.rpm\nglibc-langpack-fur-2.28-164.el8.ppc64le.rpm\nglibc-langpack-fy-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ga-2.28-164.el8.ppc64le.rpm\nglibc-langpack-gd-2.28-164.el8.ppc64le.rpm\nglibc-langpack-gez-2.28-164.el8.ppc64le.rpm\nglibc-langpack-gl-2.28-164.el8.ppc64le.rpm\nglibc-langpack-gu-2.28-164.el8.ppc64le.rpm\nglibc-langpack-gv-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ha-2.28-164.el8.ppc64le.rpm\nglibc-langpack-hak-2.28-164.el8.ppc64le.rpm\nglibc-langpack-he-2.28-164.el8.ppc64le.rpm\nglibc-langpack-hi-2.28-164.el8.ppc64le.rpm\nglibc-langpack-hif-2.28-164.el8.ppc64le.rpm\nglibc-langpack-hne-2.28-164.el8.ppc64le.rpm\nglibc-langpack-hr-2.28-164.el8.ppc64le.rpm\nglibc-langpack-hsb-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ht-2.28-164.el8.ppc64le.rpm\nglibc-langpack-hu-2.28-164.el8.ppc64le.rpm\nglibc-langpack-hy-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ia-2.28-164.el8.ppc64le.rpm\nglibc-langpack-id-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ig-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ik-2.28-164.el8.ppc64le.rpm\nglibc-langpack-is-2.28-164.el8.ppc64le.rpm\nglibc-langpack-it-2.28-164.el8.ppc64le.rpm\nglibc-langpack-iu-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ja-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ka-2.28-164.el8.ppc64le.rpm\nglibc-langpack-kab-2.28-164.el8.ppc64le.rpm\nglibc-langpack-kk-2.28-164.el8.ppc64le.rpm\nglibc-langpack-kl-2.28-164.el8.ppc64le.rpm\nglibc-langpack-km-2.28-164.el8.ppc64le.rpm\nglibc-langpack-kn-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ko-2.28-164.el8.ppc64le.rpm\nglibc-langpack-kok-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ks-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ku-2.28-164.el8.ppc64le.rpm\nglibc-langpack-kw-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ky-2.28-164.el8.ppc64le.rpm\nglibc-langpack-lb-2.28-164.el8.ppc64le.rpm\nglibc-langpack-lg-2.28-164.el8.ppc64le.rpm\nglibc-langpack-li-2.28-164.el8.ppc64le.rpm\nglibc-langpack-lij-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ln-2.28-164.el8.ppc64le.rpm\nglibc-langpack-lo-2.28-164.el8.ppc64le.rpm\nglibc-langpack-lt-2.28-164.el8.ppc64le.rpm\nglibc-langpack-lv-2.28-164.el8.ppc64le.rpm\nglibc-langpack-lzh-2.28-164.el8.ppc64le.rpm\nglibc-langpack-mag-2.28-164.el8.ppc64le.rpm\nglibc-langpack-mai-2.28-164.el8.ppc64le.rpm\nglibc-langpack-mfe-2.28-164.el8.ppc64le.rpm\nglibc-langpack-mg-2.28-164.el8.ppc64le.rpm\nglibc-langpack-mhr-2.28-164.el8.ppc64le.rpm\nglibc-langpack-mi-2.28-164.el8.ppc64le.rpm\nglibc-langpack-miq-2.28-164.el8.ppc64le.rpm\nglibc-langpack-mjw-2.28-164.el8.ppc64le.rpm\nglibc-langpack-mk-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ml-2.28-164.el8.ppc64le.rpm\nglibc-langpack-mn-2.28-164.el8.ppc64le.rpm\nglibc-langpack-mni-2.28-164.el8.ppc64le.rpm\nglibc-langpack-mr-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ms-2.28-164.el8.ppc64le.rpm\nglibc-langpack-mt-2.28-164.el8.ppc64le.rpm\nglibc-langpack-my-2.28-164.el8.ppc64le.rpm\nglibc-langpack-nan-2.28-164.el8.ppc64le.rpm\nglibc-langpack-nb-2.28-164.el8.ppc64le.rpm\nglibc-langpack-nds-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ne-2.28-164.el8.ppc64le.rpm\nglibc-langpack-nhn-2.28-164.el8.ppc64le.rpm\nglibc-langpack-niu-2.28-164.el8.ppc64le.rpm\nglibc-langpack-nl-2.28-164.el8.ppc64le.rpm\nglibc-langpack-nn-2.28-164.el8.ppc64le.rpm\nglibc-langpack-nr-2.28-164.el8.ppc64le.rpm\nglibc-langpack-nso-2.28-164.el8.ppc64le.rpm\nglibc-langpack-oc-2.28-164.el8.ppc64le.rpm\nglibc-langpack-om-2.28-164.el8.ppc64le.rpm\nglibc-langpack-or-2.28-164.el8.ppc64le.rpm\nglibc-langpack-os-2.28-164.el8.ppc64le.rpm\nglibc-langpack-pa-2.28-164.el8.ppc64le.rpm\nglibc-langpack-pap-2.28-164.el8.ppc64le.rpm\nglibc-langpack-pl-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ps-2.28-164.el8.ppc64le.rpm\nglibc-langpack-pt-2.28-164.el8.ppc64le.rpm\nglibc-langpack-quz-2.28-164.el8.ppc64le.rpm\nglibc-langpack-raj-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ro-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ru-2.28-164.el8.ppc64le.rpm\nglibc-langpack-rw-2.28-164.el8.ppc64le.rpm\nglibc-langpack-sa-2.28-164.el8.ppc64le.rpm\nglibc-langpack-sah-2.28-164.el8.ppc64le.rpm\nglibc-langpack-sat-2.28-164.el8.ppc64le.rpm\nglibc-langpack-sc-2.28-164.el8.ppc64le.rpm\nglibc-langpack-sd-2.28-164.el8.ppc64le.rpm\nglibc-langpack-se-2.28-164.el8.ppc64le.rpm\nglibc-langpack-sgs-2.28-164.el8.ppc64le.rpm\nglibc-langpack-shn-2.28-164.el8.ppc64le.rpm\nglibc-langpack-shs-2.28-164.el8.ppc64le.rpm\nglibc-langpack-si-2.28-164.el8.ppc64le.rpm\nglibc-langpack-sid-2.28-164.el8.ppc64le.rpm\nglibc-langpack-sk-2.28-164.el8.ppc64le.rpm\nglibc-langpack-sl-2.28-164.el8.ppc64le.rpm\nglibc-langpack-sm-2.28-164.el8.ppc64le.rpm\nglibc-langpack-so-2.28-164.el8.ppc64le.rpm\nglibc-langpack-sq-2.28-164.el8.ppc64le.rpm\nglibc-langpack-sr-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ss-2.28-164.el8.ppc64le.rpm\nglibc-langpack-st-2.28-164.el8.ppc64le.rpm\nglibc-langpack-sv-2.28-164.el8.ppc64le.rpm\nglibc-langpack-sw-2.28-164.el8.ppc64le.rpm\nglibc-langpack-szl-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ta-2.28-164.el8.ppc64le.rpm\nglibc-langpack-tcy-2.28-164.el8.ppc64le.rpm\nglibc-langpack-te-2.28-164.el8.ppc64le.rpm\nglibc-langpack-tg-2.28-164.el8.ppc64le.rpm\nglibc-langpack-th-2.28-164.el8.ppc64le.rpm\nglibc-langpack-the-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ti-2.28-164.el8.ppc64le.rpm\nglibc-langpack-tig-2.28-164.el8.ppc64le.rpm\nglibc-langpack-tk-2.28-164.el8.ppc64le.rpm\nglibc-langpack-tl-2.28-164.el8.ppc64le.rpm\nglibc-langpack-tn-2.28-164.el8.ppc64le.rpm\nglibc-langpack-to-2.28-164.el8.ppc64le.rpm\nglibc-langpack-tpi-2.28-164.el8.ppc64le.rpm\nglibc-langpack-tr-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ts-2.28-164.el8.ppc64le.rpm\nglibc-langpack-tt-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ug-2.28-164.el8.ppc64le.rpm\nglibc-langpack-uk-2.28-164.el8.ppc64le.rpm\nglibc-langpack-unm-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ur-2.28-164.el8.ppc64le.rpm\nglibc-langpack-uz-2.28-164.el8.ppc64le.rpm\nglibc-langpack-ve-2.28-164.el8.ppc64le.rpm\nglibc-langpack-vi-2.28-164.el8.ppc64le.rpm\nglibc-langpack-wa-2.28-164.el8.ppc64le.rpm\nglibc-langpack-wae-2.28-164.el8.ppc64le.rpm\nglibc-langpack-wal-2.28-164.el8.ppc64le.rpm\nglibc-langpack-wo-2.28-164.el8.ppc64le.rpm\nglibc-langpack-xh-2.28-164.el8.ppc64le.rpm\nglibc-langpack-yi-2.28-164.el8.ppc64le.rpm\nglibc-langpack-yo-2.28-164.el8.ppc64le.rpm\nglibc-langpack-yue-2.28-164.el8.ppc64le.rpm\nglibc-langpack-yuw-2.28-164.el8.ppc64le.rpm\nglibc-langpack-zh-2.28-164.el8.ppc64le.rpm\nglibc-langpack-zu-2.28-164.el8.ppc64le.rpm\nglibc-locale-source-2.28-164.el8.ppc64le.rpm\nglibc-minimal-langpack-2.28-164.el8.ppc64le.rpm\nlibnsl-2.28-164.el8.ppc64le.rpm\nnscd-2.28-164.el8.ppc64le.rpm\nnss_db-2.28-164.el8.ppc64le.rpm\n\ns390x:\nglibc-2.28-164.el8.s390x.rpm\nglibc-all-langpacks-2.28-164.el8.s390x.rpm\nglibc-common-2.28-164.el8.s390x.rpm\nglibc-debuginfo-2.28-164.el8.s390x.rpm\nglibc-debuginfo-common-2.28-164.el8.s390x.rpm\nglibc-devel-2.28-164.el8.s390x.rpm\nglibc-headers-2.28-164.el8.s390x.rpm\nglibc-langpack-aa-2.28-164.el8.s390x.rpm\nglibc-langpack-af-2.28-164.el8.s390x.rpm\nglibc-langpack-agr-2.28-164.el8.s390x.rpm\nglibc-langpack-ak-2.28-164.el8.s390x.rpm\nglibc-langpack-am-2.28-164.el8.s390x.rpm\nglibc-langpack-an-2.28-164.el8.s390x.rpm\nglibc-langpack-anp-2.28-164.el8.s390x.rpm\nglibc-langpack-ar-2.28-164.el8.s390x.rpm\nglibc-langpack-as-2.28-164.el8.s390x.rpm\nglibc-langpack-ast-2.28-164.el8.s390x.rpm\nglibc-langpack-ayc-2.28-164.el8.s390x.rpm\nglibc-langpack-az-2.28-164.el8.s390x.rpm\nglibc-langpack-be-2.28-164.el8.s390x.rpm\nglibc-langpack-bem-2.28-164.el8.s390x.rpm\nglibc-langpack-ber-2.28-164.el8.s390x.rpm\nglibc-langpack-bg-2.28-164.el8.s390x.rpm\nglibc-langpack-bhb-2.28-164.el8.s390x.rpm\nglibc-langpack-bho-2.28-164.el8.s390x.rpm\nglibc-langpack-bi-2.28-164.el8.s390x.rpm\nglibc-langpack-bn-2.28-164.el8.s390x.rpm\nglibc-langpack-bo-2.28-164.el8.s390x.rpm\nglibc-langpack-br-2.28-164.el8.s390x.rpm\nglibc-langpack-brx-2.28-164.el8.s390x.rpm\nglibc-langpack-bs-2.28-164.el8.s390x.rpm\nglibc-langpack-byn-2.28-164.el8.s390x.rpm\nglibc-langpack-ca-2.28-164.el8.s390x.rpm\nglibc-langpack-ce-2.28-164.el8.s390x.rpm\nglibc-langpack-chr-2.28-164.el8.s390x.rpm\nglibc-langpack-cmn-2.28-164.el8.s390x.rpm\nglibc-langpack-crh-2.28-164.el8.s390x.rpm\nglibc-langpack-cs-2.28-164.el8.s390x.rpm\nglibc-langpack-csb-2.28-164.el8.s390x.rpm\nglibc-langpack-cv-2.28-164.el8.s390x.rpm\nglibc-langpack-cy-2.28-164.el8.s390x.rpm\nglibc-langpack-da-2.28-164.el8.s390x.rpm\nglibc-langpack-de-2.28-164.el8.s390x.rpm\nglibc-langpack-doi-2.28-164.el8.s390x.rpm\nglibc-langpack-dsb-2.28-164.el8.s390x.rpm\nglibc-langpack-dv-2.28-164.el8.s390x.rpm\nglibc-langpack-dz-2.28-164.el8.s390x.rpm\nglibc-langpack-el-2.28-164.el8.s390x.rpm\nglibc-langpack-en-2.28-164.el8.s390x.rpm\nglibc-langpack-eo-2.28-164.el8.s390x.rpm\nglibc-langpack-es-2.28-164.el8.s390x.rpm\nglibc-langpack-et-2.28-164.el8.s390x.rpm\nglibc-langpack-eu-2.28-164.el8.s390x.rpm\nglibc-langpack-fa-2.28-164.el8.s390x.rpm\nglibc-langpack-ff-2.28-164.el8.s390x.rpm\nglibc-langpack-fi-2.28-164.el8.s390x.rpm\nglibc-langpack-fil-2.28-164.el8.s390x.rpm\nglibc-langpack-fo-2.28-164.el8.s390x.rpm\nglibc-langpack-fr-2.28-164.el8.s390x.rpm\nglibc-langpack-fur-2.28-164.el8.s390x.rpm\nglibc-langpack-fy-2.28-164.el8.s390x.rpm\nglibc-langpack-ga-2.28-164.el8.s390x.rpm\nglibc-langpack-gd-2.28-164.el8.s390x.rpm\nglibc-langpack-gez-2.28-164.el8.s390x.rpm\nglibc-langpack-gl-2.28-164.el8.s390x.rpm\nglibc-langpack-gu-2.28-164.el8.s390x.rpm\nglibc-langpack-gv-2.28-164.el8.s390x.rpm\nglibc-langpack-ha-2.28-164.el8.s390x.rpm\nglibc-langpack-hak-2.28-164.el8.s390x.rpm\nglibc-langpack-he-2.28-164.el8.s390x.rpm\nglibc-langpack-hi-2.28-164.el8.s390x.rpm\nglibc-langpack-hif-2.28-164.el8.s390x.rpm\nglibc-langpack-hne-2.28-164.el8.s390x.rpm\nglibc-langpack-hr-2.28-164.el8.s390x.rpm\nglibc-langpack-hsb-2.28-164.el8.s390x.rpm\nglibc-langpack-ht-2.28-164.el8.s390x.rpm\nglibc-langpack-hu-2.28-164.el8.s390x.rpm\nglibc-langpack-hy-2.28-164.el8.s390x.rpm\nglibc-langpack-ia-2.28-164.el8.s390x.rpm\nglibc-langpack-id-2.28-164.el8.s390x.rpm\nglibc-langpack-ig-2.28-164.el8.s390x.rpm\nglibc-langpack-ik-2.28-164.el8.s390x.rpm\nglibc-langpack-is-2.28-164.el8.s390x.rpm\nglibc-langpack-it-2.28-164.el8.s390x.rpm\nglibc-langpack-iu-2.28-164.el8.s390x.rpm\nglibc-langpack-ja-2.28-164.el8.s390x.rpm\nglibc-langpack-ka-2.28-164.el8.s390x.rpm\nglibc-langpack-kab-2.28-164.el8.s390x.rpm\nglibc-langpack-kk-2.28-164.el8.s390x.rpm\nglibc-langpack-kl-2.28-164.el8.s390x.rpm\nglibc-langpack-km-2.28-164.el8.s390x.rpm\nglibc-langpack-kn-2.28-164.el8.s390x.rpm\nglibc-langpack-ko-2.28-164.el8.s390x.rpm\nglibc-langpack-kok-2.28-164.el8.s390x.rpm\nglibc-langpack-ks-2.28-164.el8.s390x.rpm\nglibc-langpack-ku-2.28-164.el8.s390x.rpm\nglibc-langpack-kw-2.28-164.el8.s390x.rpm\nglibc-langpack-ky-2.28-164.el8.s390x.rpm\nglibc-langpack-lb-2.28-164.el8.s390x.rpm\nglibc-langpack-lg-2.28-164.el8.s390x.rpm\nglibc-langpack-li-2.28-164.el8.s390x.rpm\nglibc-langpack-lij-2.28-164.el8.s390x.rpm\nglibc-langpack-ln-2.28-164.el8.s390x.rpm\nglibc-langpack-lo-2.28-164.el8.s390x.rpm\nglibc-langpack-lt-2.28-164.el8.s390x.rpm\nglibc-langpack-lv-2.28-164.el8.s390x.rpm\nglibc-langpack-lzh-2.28-164.el8.s390x.rpm\nglibc-langpack-mag-2.28-164.el8.s390x.rpm\nglibc-langpack-mai-2.28-164.el8.s390x.rpm\nglibc-langpack-mfe-2.28-164.el8.s390x.rpm\nglibc-langpack-mg-2.28-164.el8.s390x.rpm\nglibc-langpack-mhr-2.28-164.el8.s390x.rpm\nglibc-langpack-mi-2.28-164.el8.s390x.rpm\nglibc-langpack-miq-2.28-164.el8.s390x.rpm\nglibc-langpack-mjw-2.28-164.el8.s390x.rpm\nglibc-langpack-mk-2.28-164.el8.s390x.rpm\nglibc-langpack-ml-2.28-164.el8.s390x.rpm\nglibc-langpack-mn-2.28-164.el8.s390x.rpm\nglibc-langpack-mni-2.28-164.el8.s390x.rpm\nglibc-langpack-mr-2.28-164.el8.s390x.rpm\nglibc-langpack-ms-2.28-164.el8.s390x.rpm\nglibc-langpack-mt-2.28-164.el8.s390x.rpm\nglibc-langpack-my-2.28-164.el8.s390x.rpm\nglibc-langpack-nan-2.28-164.el8.s390x.rpm\nglibc-langpack-nb-2.28-164.el8.s390x.rpm\nglibc-langpack-nds-2.28-164.el8.s390x.rpm\nglibc-langpack-ne-2.28-164.el8.s390x.rpm\nglibc-langpack-nhn-2.28-164.el8.s390x.rpm\nglibc-langpack-niu-2.28-164.el8.s390x.rpm\nglibc-langpack-nl-2.28-164.el8.s390x.rpm\nglibc-langpack-nn-2.28-164.el8.s390x.rpm\nglibc-langpack-nr-2.28-164.el8.s390x.rpm\nglibc-langpack-nso-2.28-164.el8.s390x.rpm\nglibc-langpack-oc-2.28-164.el8.s390x.rpm\nglibc-langpack-om-2.28-164.el8.s390x.rpm\nglibc-langpack-or-2.28-164.el8.s390x.rpm\nglibc-langpack-os-2.28-164.el8.s390x.rpm\nglibc-langpack-pa-2.28-164.el8.s390x.rpm\nglibc-langpack-pap-2.28-164.el8.s390x.rpm\nglibc-langpack-pl-2.28-164.el8.s390x.rpm\nglibc-langpack-ps-2.28-164.el8.s390x.rpm\nglibc-langpack-pt-2.28-164.el8.s390x.rpm\nglibc-langpack-quz-2.28-164.el8.s390x.rpm\nglibc-langpack-raj-2.28-164.el8.s390x.rpm\nglibc-langpack-ro-2.28-164.el8.s390x.rpm\nglibc-langpack-ru-2.28-164.el8.s390x.rpm\nglibc-langpack-rw-2.28-164.el8.s390x.rpm\nglibc-langpack-sa-2.28-164.el8.s390x.rpm\nglibc-langpack-sah-2.28-164.el8.s390x.rpm\nglibc-langpack-sat-2.28-164.el8.s390x.rpm\nglibc-langpack-sc-2.28-164.el8.s390x.rpm\nglibc-langpack-sd-2.28-164.el8.s390x.rpm\nglibc-langpack-se-2.28-164.el8.s390x.rpm\nglibc-langpack-sgs-2.28-164.el8.s390x.rpm\nglibc-langpack-shn-2.28-164.el8.s390x.rpm\nglibc-langpack-shs-2.28-164.el8.s390x.rpm\nglibc-langpack-si-2.28-164.el8.s390x.rpm\nglibc-langpack-sid-2.28-164.el8.s390x.rpm\nglibc-langpack-sk-2.28-164.el8.s390x.rpm\nglibc-langpack-sl-2.28-164.el8.s390x.rpm\nglibc-langpack-sm-2.28-164.el8.s390x.rpm\nglibc-langpack-so-2.28-164.el8.s390x.rpm\nglibc-langpack-sq-2.28-164.el8.s390x.rpm\nglibc-langpack-sr-2.28-164.el8.s390x.rpm\nglibc-langpack-ss-2.28-164.el8.s390x.rpm\nglibc-langpack-st-2.28-164.el8.s390x.rpm\nglibc-langpack-sv-2.28-164.el8.s390x.rpm\nglibc-langpack-sw-2.28-164.el8.s390x.rpm\nglibc-langpack-szl-2.28-164.el8.s390x.rpm\nglibc-langpack-ta-2.28-164.el8.s390x.rpm\nglibc-langpack-tcy-2.28-164.el8.s390x.rpm\nglibc-langpack-te-2.28-164.el8.s390x.rpm\nglibc-langpack-tg-2.28-164.el8.s390x.rpm\nglibc-langpack-th-2.28-164.el8.s390x.rpm\nglibc-langpack-the-2.28-164.el8.s390x.rpm\nglibc-langpack-ti-2.28-164.el8.s390x.rpm\nglibc-langpack-tig-2.28-164.el8.s390x.rpm\nglibc-langpack-tk-2.28-164.el8.s390x.rpm\nglibc-langpack-tl-2.28-164.el8.s390x.rpm\nglibc-langpack-tn-2.28-164.el8.s390x.rpm\nglibc-langpack-to-2.28-164.el8.s390x.rpm\nglibc-langpack-tpi-2.28-164.el8.s390x.rpm\nglibc-langpack-tr-2.28-164.el8.s390x.rpm\nglibc-langpack-ts-2.28-164.el8.s390x.rpm\nglibc-langpack-tt-2.28-164.el8.s390x.rpm\nglibc-langpack-ug-2.28-164.el8.s390x.rpm\nglibc-langpack-uk-2.28-164.el8.s390x.rpm\nglibc-langpack-unm-2.28-164.el8.s390x.rpm\nglibc-langpack-ur-2.28-164.el8.s390x.rpm\nglibc-langpack-uz-2.28-164.el8.s390x.rpm\nglibc-langpack-ve-2.28-164.el8.s390x.rpm\nglibc-langpack-vi-2.28-164.el8.s390x.rpm\nglibc-langpack-wa-2.28-164.el8.s390x.rpm\nglibc-langpack-wae-2.28-164.el8.s390x.rpm\nglibc-langpack-wal-2.28-164.el8.s390x.rpm\nglibc-langpack-wo-2.28-164.el8.s390x.rpm\nglibc-langpack-xh-2.28-164.el8.s390x.rpm\nglibc-langpack-yi-2.28-164.el8.s390x.rpm\nglibc-langpack-yo-2.28-164.el8.s390x.rpm\nglibc-langpack-yue-2.28-164.el8.s390x.rpm\nglibc-langpack-yuw-2.28-164.el8.s390x.rpm\nglibc-langpack-zh-2.28-164.el8.s390x.rpm\nglibc-langpack-zu-2.28-164.el8.s390x.rpm\nglibc-locale-source-2.28-164.el8.s390x.rpm\nglibc-minimal-langpack-2.28-164.el8.s390x.rpm\nlibnsl-2.28-164.el8.s390x.rpm\nnscd-2.28-164.el8.s390x.rpm\nnss_db-2.28-164.el8.s390x.rpm\n\nx86_64:\nglibc-2.28-164.el8.i686.rpm\nglibc-2.28-164.el8.x86_64.rpm\nglibc-all-langpacks-2.28-164.el8.x86_64.rpm\nglibc-common-2.28-164.el8.x86_64.rpm\nglibc-debuginfo-2.28-164.el8.i686.rpm\nglibc-debuginfo-2.28-164.el8.x86_64.rpm\nglibc-debuginfo-common-2.28-164.el8.i686.rpm\nglibc-debuginfo-common-2.28-164.el8.x86_64.rpm\nglibc-devel-2.28-164.el8.i686.rpm\nglibc-devel-2.28-164.el8.x86_64.rpm\nglibc-headers-2.28-164.el8.i686.rpm\nglibc-headers-2.28-164.el8.x86_64.rpm\nglibc-langpack-aa-2.28-164.el8.x86_64.rpm\nglibc-langpack-af-2.28-164.el8.x86_64.rpm\nglibc-langpack-agr-2.28-164.el8.x86_64.rpm\nglibc-langpack-ak-2.28-164.el8.x86_64.rpm\nglibc-langpack-am-2.28-164.el8.x86_64.rpm\nglibc-langpack-an-2.28-164.el8.x86_64.rpm\nglibc-langpack-anp-2.28-164.el8.x86_64.rpm\nglibc-langpack-ar-2.28-164.el8.x86_64.rpm\nglibc-langpack-as-2.28-164.el8.x86_64.rpm\nglibc-langpack-ast-2.28-164.el8.x86_64.rpm\nglibc-langpack-ayc-2.28-164.el8.x86_64.rpm\nglibc-langpack-az-2.28-164.el8.x86_64.rpm\nglibc-langpack-be-2.28-164.el8.x86_64.rpm\nglibc-langpack-bem-2.28-164.el8.x86_64.rpm\nglibc-langpack-ber-2.28-164.el8.x86_64.rpm\nglibc-langpack-bg-2.28-164.el8.x86_64.rpm\nglibc-langpack-bhb-2.28-164.el8.x86_64.rpm\nglibc-langpack-bho-2.28-164.el8.x86_64.rpm\nglibc-langpack-bi-2.28-164.el8.x86_64.rpm\nglibc-langpack-bn-2.28-164.el8.x86_64.rpm\nglibc-langpack-bo-2.28-164.el8.x86_64.rpm\nglibc-langpack-br-2.28-164.el8.x86_64.rpm\nglibc-langpack-brx-2.28-164.el8.x86_64.rpm\nglibc-langpack-bs-2.28-164.el8.x86_64.rpm\nglibc-langpack-byn-2.28-164.el8.x86_64.rpm\nglibc-langpack-ca-2.28-164.el8.x86_64.rpm\nglibc-langpack-ce-2.28-164.el8.x86_64.rpm\nglibc-langpack-chr-2.28-164.el8.x86_64.rpm\nglibc-langpack-cmn-2.28-164.el8.x86_64.rpm\nglibc-langpack-crh-2.28-164.el8.x86_64.rpm\nglibc-langpack-cs-2.28-164.el8.x86_64.rpm\nglibc-langpack-csb-2.28-164.el8.x86_64.rpm\nglibc-langpack-cv-2.28-164.el8.x86_64.rpm\nglibc-langpack-cy-2.28-164.el8.x86_64.rpm\nglibc-langpack-da-2.28-164.el8.x86_64.rpm\nglibc-langpack-de-2.28-164.el8.x86_64.rpm\nglibc-langpack-doi-2.28-164.el8.x86_64.rpm\nglibc-langpack-dsb-2.28-164.el8.x86_64.rpm\nglibc-langpack-dv-2.28-164.el8.x86_64.rpm\nglibc-langpack-dz-2.28-164.el8.x86_64.rpm\nglibc-langpack-el-2.28-164.el8.x86_64.rpm\nglibc-langpack-en-2.28-164.el8.x86_64.rpm\nglibc-langpack-eo-2.28-164.el8.x86_64.rpm\nglibc-langpack-es-2.28-164.el8.x86_64.rpm\nglibc-langpack-et-2.28-164.el8.x86_64.rpm\nglibc-langpack-eu-2.28-164.el8.x86_64.rpm\nglibc-langpack-fa-2.28-164.el8.x86_64.rpm\nglibc-langpack-ff-2.28-164.el8.x86_64.rpm\nglibc-langpack-fi-2.28-164.el8.x86_64.rpm\nglibc-langpack-fil-2.28-164.el8.x86_64.rpm\nglibc-langpack-fo-2.28-164.el8.x86_64.rpm\nglibc-langpack-fr-2.28-164.el8.x86_64.rpm\nglibc-langpack-fur-2.28-164.el8.x86_64.rpm\nglibc-langpack-fy-2.28-164.el8.x86_64.rpm\nglibc-langpack-ga-2.28-164.el8.x86_64.rpm\nglibc-langpack-gd-2.28-164.el8.x86_64.rpm\nglibc-langpack-gez-2.28-164.el8.x86_64.rpm\nglibc-langpack-gl-2.28-164.el8.x86_64.rpm\nglibc-langpack-gu-2.28-164.el8.x86_64.rpm\nglibc-langpack-gv-2.28-164.el8.x86_64.rpm\nglibc-langpack-ha-2.28-164.el8.x86_64.rpm\nglibc-langpack-hak-2.28-164.el8.x86_64.rpm\nglibc-langpack-he-2.28-164.el8.x86_64.rpm\nglibc-langpack-hi-2.28-164.el8.x86_64.rpm\nglibc-langpack-hif-2.28-164.el8.x86_64.rpm\nglibc-langpack-hne-2.28-164.el8.x86_64.rpm\nglibc-langpack-hr-2.28-164.el8.x86_64.rpm\nglibc-langpack-hsb-2.28-164.el8.x86_64.rpm\nglibc-langpack-ht-2.28-164.el8.x86_64.rpm\nglibc-langpack-hu-2.28-164.el8.x86_64.rpm\nglibc-langpack-hy-2.28-164.el8.x86_64.rpm\nglibc-langpack-ia-2.28-164.el8.x86_64.rpm\nglibc-langpack-id-2.28-164.el8.x86_64.rpm\nglibc-langpack-ig-2.28-164.el8.x86_64.rpm\nglibc-langpack-ik-2.28-164.el8.x86_64.rpm\nglibc-langpack-is-2.28-164.el8.x86_64.rpm\nglibc-langpack-it-2.28-164.el8.x86_64.rpm\nglibc-langpack-iu-2.28-164.el8.x86_64.rpm\nglibc-langpack-ja-2.28-164.el8.x86_64.rpm\nglibc-langpack-ka-2.28-164.el8.x86_64.rpm\nglibc-langpack-kab-2.28-164.el8.x86_64.rpm\nglibc-langpack-kk-2.28-164.el8.x86_64.rpm\nglibc-langpack-kl-2.28-164.el8.x86_64.rpm\nglibc-langpack-km-2.28-164.el8.x86_64.rpm\nglibc-langpack-kn-2.28-164.el8.x86_64.rpm\nglibc-langpack-ko-2.28-164.el8.x86_64.rpm\nglibc-langpack-kok-2.28-164.el8.x86_64.rpm\nglibc-langpack-ks-2.28-164.el8.x86_64.rpm\nglibc-langpack-ku-2.28-164.el8.x86_64.rpm\nglibc-langpack-kw-2.28-164.el8.x86_64.rpm\nglibc-langpack-ky-2.28-164.el8.x86_64.rpm\nglibc-langpack-lb-2.28-164.el8.x86_64.rpm\nglibc-langpack-lg-2.28-164.el8.x86_64.rpm\nglibc-langpack-li-2.28-164.el8.x86_64.rpm\nglibc-langpack-lij-2.28-164.el8.x86_64.rpm\nglibc-langpack-ln-2.28-164.el8.x86_64.rpm\nglibc-langpack-lo-2.28-164.el8.x86_64.rpm\nglibc-langpack-lt-2.28-164.el8.x86_64.rpm\nglibc-langpack-lv-2.28-164.el8.x86_64.rpm\nglibc-langpack-lzh-2.28-164.el8.x86_64.rpm\nglibc-langpack-mag-2.28-164.el8.x86_64.rpm\nglibc-langpack-mai-2.28-164.el8.x86_64.rpm\nglibc-langpack-mfe-2.28-164.el8.x86_64.rpm\nglibc-langpack-mg-2.28-164.el8.x86_64.rpm\nglibc-langpack-mhr-2.28-164.el8.x86_64.rpm\nglibc-langpack-mi-2.28-164.el8.x86_64.rpm\nglibc-langpack-miq-2.28-164.el8.x86_64.rpm\nglibc-langpack-mjw-2.28-164.el8.x86_64.rpm\nglibc-langpack-mk-2.28-164.el8.x86_64.rpm\nglibc-langpack-ml-2.28-164.el8.x86_64.rpm\nglibc-langpack-mn-2.28-164.el8.x86_64.rpm\nglibc-langpack-mni-2.28-164.el8.x86_64.rpm\nglibc-langpack-mr-2.28-164.el8.x86_64.rpm\nglibc-langpack-ms-2.28-164.el8.x86_64.rpm\nglibc-langpack-mt-2.28-164.el8.x86_64.rpm\nglibc-langpack-my-2.28-164.el8.x86_64.rpm\nglibc-langpack-nan-2.28-164.el8.x86_64.rpm\nglibc-langpack-nb-2.28-164.el8.x86_64.rpm\nglibc-langpack-nds-2.28-164.el8.x86_64.rpm\nglibc-langpack-ne-2.28-164.el8.x86_64.rpm\nglibc-langpack-nhn-2.28-164.el8.x86_64.rpm\nglibc-langpack-niu-2.28-164.el8.x86_64.rpm\nglibc-langpack-nl-2.28-164.el8.x86_64.rpm\nglibc-langpack-nn-2.28-164.el8.x86_64.rpm\nglibc-langpack-nr-2.28-164.el8.x86_64.rpm\nglibc-langpack-nso-2.28-164.el8.x86_64.rpm\nglibc-langpack-oc-2.28-164.el8.x86_64.rpm\nglibc-langpack-om-2.28-164.el8.x86_64.rpm\nglibc-langpack-or-2.28-164.el8.x86_64.rpm\nglibc-langpack-os-2.28-164.el8.x86_64.rpm\nglibc-langpack-pa-2.28-164.el8.x86_64.rpm\nglibc-langpack-pap-2.28-164.el8.x86_64.rpm\nglibc-langpack-pl-2.28-164.el8.x86_64.rpm\nglibc-langpack-ps-2.28-164.el8.x86_64.rpm\nglibc-langpack-pt-2.28-164.el8.x86_64.rpm\nglibc-langpack-quz-2.28-164.el8.x86_64.rpm\nglibc-langpack-raj-2.28-164.el8.x86_64.rpm\nglibc-langpack-ro-2.28-164.el8.x86_64.rpm\nglibc-langpack-ru-2.28-164.el8.x86_64.rpm\nglibc-langpack-rw-2.28-164.el8.x86_64.rpm\nglibc-langpack-sa-2.28-164.el8.x86_64.rpm\nglibc-langpack-sah-2.28-164.el8.x86_64.rpm\nglibc-langpack-sat-2.28-164.el8.x86_64.rpm\nglibc-langpack-sc-2.28-164.el8.x86_64.rpm\nglibc-langpack-sd-2.28-164.el8.x86_64.rpm\nglibc-langpack-se-2.28-164.el8.x86_64.rpm\nglibc-langpack-sgs-2.28-164.el8.x86_64.rpm\nglibc-langpack-shn-2.28-164.el8.x86_64.rpm\nglibc-langpack-shs-2.28-164.el8.x86_64.rpm\nglibc-langpack-si-2.28-164.el8.x86_64.rpm\nglibc-langpack-sid-2.28-164.el8.x86_64.rpm\nglibc-langpack-sk-2.28-164.el8.x86_64.rpm\nglibc-langpack-sl-2.28-164.el8.x86_64.rpm\nglibc-langpack-sm-2.28-164.el8.x86_64.rpm\nglibc-langpack-so-2.28-164.el8.x86_64.rpm\nglibc-langpack-sq-2.28-164.el8.x86_64.rpm\nglibc-langpack-sr-2.28-164.el8.x86_64.rpm\nglibc-langpack-ss-2.28-164.el8.x86_64.rpm\nglibc-langpack-st-2.28-164.el8.x86_64.rpm\nglibc-langpack-sv-2.28-164.el8.x86_64.rpm\nglibc-langpack-sw-2.28-164.el8.x86_64.rpm\nglibc-langpack-szl-2.28-164.el8.x86_64.rpm\nglibc-langpack-ta-2.28-164.el8.x86_64.rpm\nglibc-langpack-tcy-2.28-164.el8.x86_64.rpm\nglibc-langpack-te-2.28-164.el8.x86_64.rpm\nglibc-langpack-tg-2.28-164.el8.x86_64.rpm\nglibc-langpack-th-2.28-164.el8.x86_64.rpm\nglibc-langpack-the-2.28-164.el8.x86_64.rpm\nglibc-langpack-ti-2.28-164.el8.x86_64.rpm\nglibc-langpack-tig-2.28-164.el8.x86_64.rpm\nglibc-langpack-tk-2.28-164.el8.x86_64.rpm\nglibc-langpack-tl-2.28-164.el8.x86_64.rpm\nglibc-langpack-tn-2.28-164.el8.x86_64.rpm\nglibc-langpack-to-2.28-164.el8.x86_64.rpm\nglibc-langpack-tpi-2.28-164.el8.x86_64.rpm\nglibc-langpack-tr-2.28-164.el8.x86_64.rpm\nglibc-langpack-ts-2.28-164.el8.x86_64.rpm\nglibc-langpack-tt-2.28-164.el8.x86_64.rpm\nglibc-langpack-ug-2.28-164.el8.x86_64.rpm\nglibc-langpack-uk-2.28-164.el8.x86_64.rpm\nglibc-langpack-unm-2.28-164.el8.x86_64.rpm\nglibc-langpack-ur-2.28-164.el8.x86_64.rpm\nglibc-langpack-uz-2.28-164.el8.x86_64.rpm\nglibc-langpack-ve-2.28-164.el8.x86_64.rpm\nglibc-langpack-vi-2.28-164.el8.x86_64.rpm\nglibc-langpack-wa-2.28-164.el8.x86_64.rpm\nglibc-langpack-wae-2.28-164.el8.x86_64.rpm\nglibc-langpack-wal-2.28-164.el8.x86_64.rpm\nglibc-langpack-wo-2.28-164.el8.x86_64.rpm\nglibc-langpack-xh-2.28-164.el8.x86_64.rpm\nglibc-langpack-yi-2.28-164.el8.x86_64.rpm\nglibc-langpack-yo-2.28-164.el8.x86_64.rpm\nglibc-langpack-yue-2.28-164.el8.x86_64.rpm\nglibc-langpack-yuw-2.28-164.el8.x86_64.rpm\nglibc-langpack-zh-2.28-164.el8.x86_64.rpm\nglibc-langpack-zu-2.28-164.el8.x86_64.rpm\nglibc-locale-source-2.28-164.el8.x86_64.rpm\nglibc-minimal-langpack-2.28-164.el8.x86_64.rpm\nlibnsl-2.28-164.el8.i686.rpm\nlibnsl-2.28-164.el8.x86_64.rpm\nnscd-2.28-164.el8.x86_64.rpm\nnss_db-2.28-164.el8.i686.rpm\nnss_db-2.28-164.el8.x86_64.rpm\n\nRed Hat Enterprise Linux CRB (v. 8):\n\naarch64:\nglibc-benchtests-2.28-164.el8.aarch64.rpm\nglibc-debuginfo-2.28-164.el8.aarch64.rpm\nglibc-nss-devel-2.28-164.el8.aarch64.rpm\nglibc-static-2.28-164.el8.aarch64.rpm\nnss_hesiod-2.28-164.el8.aarch64.rpm\n\nppc64le:\nglibc-benchtests-2.28-164.el8.ppc64le.rpm\nglibc-debuginfo-2.28-164.el8.ppc64le.rpm\nglibc-debuginfo-common-2.28-164.el8.ppc64le.rpm\nglibc-nss-devel-2.28-164.el8.ppc64le.rpm\nglibc-static-2.28-164.el8.ppc64le.rpm\nnss_hesiod-2.28-164.el8.ppc64le.rpm\n\ns390x:\nglibc-benchtests-2.28-164.el8.s390x.rpm\nglibc-debuginfo-2.28-164.el8.s390x.rpm\nglibc-debuginfo-common-2.28-164.el8.s390x.rpm\nglibc-nss-devel-2.28-164.el8.s390x.rpm\nglibc-static-2.28-164.el8.s390x.rpm\nnss_hesiod-2.28-164.el8.s390x.rpm\n\nx86_64:\nglibc-benchtests-2.28-164.el8.x86_64.rpm\nglibc-debuginfo-2.28-164.el8.i686.rpm\nglibc-debuginfo-2.28-164.el8.x86_64.rpm\nglibc-debuginfo-common-2.28-164.el8.i686.rpm\nglibc-debuginfo-common-2.28-164.el8.x86_64.rpm\nglibc-nss-devel-2.28-164.el8.i686.rpm\nglibc-nss-devel-2.28-164.el8.x86_64.rpm\nglibc-static-2.28-164.el8.i686.rpm\nglibc-static-2.28-164.el8.x86_64.rpm\nnss_hesiod-2.28-164.el8.i686.rpm\nnss_hesiod-2.28-164.el8.x86_64.rpm\n\nThese packages are GPG signed by Red Hat for security. Our key and\ndetails on how to verify the signature are available from\nhttps://access.redhat.com/security/team/key/\n\n7. References:\n\nhttps://access.redhat.com/security/cve/CVE-2021-27645\nhttps://access.redhat.com/security/cve/CVE-2021-33574\nhttps://access.redhat.com/security/cve/CVE-2021-35942\nhttps://access.redhat.com/security/updates/classification/#moderate\nhttps://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/8.5_release_notes/\n\n8. Contact:\n\nThe Red Hat security contact is \u003csecalert@redhat.com\u003e. More contact\ndetails at https://access.redhat.com/security/team/contact/\n\nCopyright 2021 Red Hat, Inc. \n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1\n\niQIVAwUBYYreQ9zjgjWX9erEAQhH6Q//Sbg528iEujRXW+yNO7ZtLCcgn8oDHgiD\nTvPa6VRcP/E4lByAPC3fGxxrcoXnDbD+vB2Ew/R1l4rAT1WP/WCaqX+gY1b4eVLU\nHxsZAfg849CCe4k0Bai5MtB/BU6/WEIUD5ACACEhIPfgPoNUONAeZLmNPFRj3Rpj\nSk3NmXlG9lkkrfGexwGokGDPsq62pZqwbF+oPkTfCFFvbzrBF/sS8CfkB5Rws8tM\naBJXEgpnyJlDJ0FDoQ7yuSVZNfuVbnFcJmAWr8c+eeR46C0aWfl3ETxNbcNCCuUj\ndTBjthu7ZG/88DuOVQwGIZOyC8HNwhzVIHPK0SVmCJeF3eHULJ1mYwaBqQ6YzwuP\nTCox0iZMA7vHsGvB0OCJbARfZKeIJTe7T9vqQxOGaOdI5QgttZObgLJub4Y8kjiq\n61Mxx5pKumqRy/k0p9SAn0oHbXC9iholWg/TWblj31TJY4FXMLTzJckt96IjYyTq\nLskhunzwcwE3FtmlYBVc4nDty/+lTnUbMFrxynPng8obd0sRINn/ZEoZF32iLjoB\nLUs04wy0iG2segTBbbG+Se80NnjABc8Eedy+ksycT1PAt1sWfLfqUO3OFsN+0995\nu+mDEbqXullTWozC3o/AUzsDGS/Cf2EFEPjhfcoxecQRqj+jG316CnBRyY0juSK1\nqL31MTX7XJI=i/Jb\n-----END PGP SIGNATURE-----\n\n--\nRHSA-announce mailing list\nRHSA-announce@redhat.com\nhttps://listman.redhat.com/mailman/listinfo/rhsa-announce\n. Description:\n\nRed Hat Advanced Cluster Management for Kubernetes 2.2.10 images\n\nRed Hat Advanced Cluster Management for Kubernetes provides the\ncapabilities to address common challenges that administrators and site\nreliability engineers face as they work across a range of public and\nprivate cloud environments. \n\nClusters and applications are all visible and managed from a single console\n\u2014 with security policy built in. See the following Release Notes documentation, which\nwill be updated shortly for this release, for additional details about this\nrelease:\n\nhttps://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.2/html/release_notes/\n\nSecurity fixes: \n\n* CVE-2021-3795 semver-regex: inefficient regular expression complexity\n\n* CVE-2021-23440 nodejs-set-value: type confusion allows bypass of\nCVE-2019-10747\n\nRelated bugs: \n\n* RHACM 2.2.10 images (Bugzilla #2013652)\n\n3. Bugs fixed (https://bugzilla.redhat.com/):\n\n2004944 - CVE-2021-23440 nodejs-set-value: type confusion allows bypass of CVE-2019-10747\n2006009 - CVE-2021-3795 semver-regex: inefficient regular expression complexity\n2013652 - RHACM 2.2.10 images\n\n5. Bugs fixed (https://bugzilla.redhat.com/):\n\n1963232 - CVE-2021-33194 golang: x/net/html: infinite loop in ParseFragment\n\n5. JIRA issues fixed (https://issues.jboss.org/):\n\nLOG-1168 - Disable hostname verification in syslog TLS settings\nLOG-1235 - Using HTTPS without a secret does not translate into the correct \u0027scheme\u0027 value in Fluentd\nLOG-1375 - ssl_ca_cert should be optional\nLOG-1378 - CLO should support sasl_plaintext(Password over http)\nLOG-1392 - In fluentd config, flush_interval can\u0027t be set with flush_mode=immediate\nLOG-1494 - Syslog output is serializing json incorrectly\nLOG-1555 - Fluentd logs emit transaction failed: error_class=NoMethodError while forwarding to external syslog server\nLOG-1575 - Rejected by Elasticsearch and unexpected json-parsing\nLOG-1735 - Regression introducing flush_at_shutdown \nLOG-1774 - The collector logs should be excluded in fluent.conf\nLOG-1776 - fluentd total_limit_size sets value beyond available space\nLOG-1822 - OpenShift Alerting Rules Style-Guide Compliance\nLOG-1859 - CLO Should not error and exit early on missing ca-bundle when cluster wide proxy is not enabled\nLOG-1862 - Unsupported kafka parameters when enabled Kafka SASL\nLOG-1903 - Fix the Display of ClusterLogging type in OLM\nLOG-1911 - CLF API changes to Opt-in to multiline error detection\nLOG-1918 - Alert `FluentdNodeDown` always firing \nLOG-1939 - Opt-in multiline detection breaks cloudwatch forwarding\n\n6. Description:\n\nRed Hat OpenShift Container Storage is software-defined storage integrated\nwith and optimized for the Red Hat OpenShift Container Platform. \nRed Hat OpenShift Container Storage is highly scalable, production-grade\npersistent storage for stateful applications running in the Red Hat\nOpenShift Container Platform. In addition to persistent storage, Red Hat\nOpenShift Container Storage provides a multicloud data management service\nwith an S3 compatible API. \n\nBug Fix(es):\n\n* Previously, when the namespace store target was deleted, no alert was\nsent to the namespace bucket because of an issue in calculating the\nnamespace bucket health. With this update, the issue in calculating the\nnamespace bucket health is fixed and alerts are triggered as expected. \n(BZ#1993873)\n\n* Previously, the Multicloud Object Gateway (MCG) components performed\nslowly and there was a lot of pressure on the MCG components due to\nnon-optimized database queries. With this update the non-optimized\ndatabase queries are fixed which reduces the compute resources and time\ntaken for queries. Bugs fixed (https://bugzilla.redhat.com/):\n\n1993873 - [4.8.z clone] Alert NooBaaNamespaceBucketErrorState is not triggered when namespacestore\u0027s target bucket is deleted\n2006958 - CVE-2020-26301 nodejs-ssh2: Command injection by calling vulnerable method with untrusted input\n\n5", "sources": [ { "db": "NVD", "id": "CVE-2021-33574" }, { "db": "JVNDB", "id": "JVNDB-2021-002276" }, { "db": "VULHUB", "id": "VHN-393646" }, { "db": "VULMON", "id": "CVE-2021-33574" }, { "db": "PACKETSTORM", "id": "163406" }, { "db": "PACKETSTORM", "id": "165296" }, { "db": "PACKETSTORM", "id": "165286" }, { "db": "PACKETSTORM", "id": "165287" }, { "db": "PACKETSTORM", "id": "164863" }, { "db": "PACKETSTORM", "id": "165209" }, { "db": "PACKETSTORM", "id": "164967" }, { "db": "PACKETSTORM", "id": "165096" } ], "trust": 2.52 }, "external_ids": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/external_ids#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "db": "NVD", "id": "CVE-2021-33574", "trust": 3.4 }, { "db": "PACKETSTORM", "id": "163406", "trust": 0.8 }, { "db": "PACKETSTORM", "id": "164863", "trust": 0.8 }, { "db": "JVNDB", "id": "JVNDB-2021-002276", "trust": 0.8 }, { "db": "CNNVD", "id": "CNNVD-202105-1666", "trust": 0.7 }, { "db": "PACKETSTORM", "id": "166308", "trust": 0.7 }, { "db": "PACKETSTORM", "id": "165758", "trust": 0.7 }, { "db": "PACKETSTORM", "id": "165862", "trust": 0.7 }, { "db": "PACKETSTORM", "id": "166051", "trust": 0.7 }, { "db": "CS-HELP", "id": "SB2021092807", "trust": 0.6 }, { "db": "CS-HELP", "id": "SB2021070604", "trust": 0.6 }, { "db": "CS-HELP", "id": "SB2021100416", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.3935", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.4254", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.4172", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2022.0394", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.3785", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.4095", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.4019", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.3905", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.4229", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.4059", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2022.5140", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.3214", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2022.0245", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.3336", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2022.0716", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2022.1071", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2022.0493", "trust": 0.6 }, { "db": "AUSCERT", "id": "ESB-2021.3398", "trust": 0.6 }, { "db": "VULHUB", "id": "VHN-393646", "trust": 0.1 }, { "db": "VULMON", "id": "CVE-2021-33574", "trust": 0.1 }, { "db": "PACKETSTORM", "id": "165296", "trust": 0.1 }, { "db": "PACKETSTORM", "id": "165286", "trust": 0.1 }, { "db": "PACKETSTORM", "id": "165287", "trust": 0.1 }, { "db": "PACKETSTORM", "id": "165209", "trust": 0.1 }, { "db": "PACKETSTORM", "id": "164967", "trust": 0.1 }, { "db": "PACKETSTORM", "id": "165096", "trust": 0.1 } ], "sources": [ { "db": "VULHUB", "id": "VHN-393646" }, { "db": "VULMON", "id": "CVE-2021-33574" }, { "db": "JVNDB", "id": "JVNDB-2021-002276" }, { "db": "PACKETSTORM", "id": "163406" }, { "db": "PACKETSTORM", "id": "165296" }, { "db": "PACKETSTORM", "id": "165286" }, { "db": "PACKETSTORM", "id": "165287" }, { "db": "PACKETSTORM", "id": "164863" }, { "db": "PACKETSTORM", "id": "165209" }, { "db": "PACKETSTORM", "id": "164967" }, { "db": "PACKETSTORM", "id": "165096" }, { "db": "CNNVD", "id": "CNNVD-202105-1666" }, { "db": "NVD", "id": "CVE-2021-33574" } ] }, "id": "VAR-202105-1306", "iot": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/iot#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": true, "sources": [ { "db": "VULHUB", "id": "VHN-393646" } ], "trust": 0.01 }, "last_update_date": "2024-09-19T20:13:23.745000Z", "patch": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/patch#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "title": "Bug\u00a027896", "trust": 0.8, "url": "https://sourceware.org/bugzilla/show_bug.cgi?id=27896" }, { "title": "Debian CVElist Bug Report Logs: glibc: CVE-2021-33574: mq_notify does not handle separately allocated thread attributes", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=debian_cvelist_bugreportlogs\u0026qid=7a9966ec919351d3328669aa69ea5e39" }, { "title": "Red Hat: CVE-2021-33574", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=red_hat_cve_database\u0026qid=CVE-2021-33574" }, { "title": "Amazon Linux 2: ALAS2-2022-1736", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=amazon_linux2\u0026qid=ALAS2-2022-1736" }, { "title": "Arch Linux Issues: ", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=arch_linux_issues\u0026qid=CVE-2021-33574 log" }, { "title": "Red Hat: Moderate: Release of OpenShift Serverless 1.20.0", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=red_hat_security_advisories\u0026qid=RHSA-20220434 - Security Advisory" }, { "title": "Red Hat: Moderate: Red Hat OpenShift distributed tracing 2.1.0 security update", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=red_hat_security_advisories\u0026qid=RHSA-20220318 - Security Advisory" }, { "title": "Red Hat: Important: Release of containers for OSP 16.2 director operator tech preview", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=red_hat_security_advisories\u0026qid=RHSA-20220842 - Security Advisory" }, { "title": "Red Hat: Important: Red Hat OpenShift GitOps security update", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=red_hat_security_advisories\u0026qid=RHSA-20220580 - Security Advisory" }, { "title": "Red Hat: Moderate: Red Hat Advanced Cluster Management 2.2.11 security updates and bug fixes", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=red_hat_security_advisories\u0026qid=RHSA-20220856 - Security Advisory" }, { "title": "Siemens Security Advisories: Siemens Security Advisory", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=siemens_security_advisories\u0026qid=ec6577109e640dac19a6ddb978afe82d" }, { "title": "", "trust": 0.1, "url": "https://github.com/Live-Hack-CVE/CVE-2021-33574 " }, { "title": "CVE-2021-33574", "trust": 0.1, "url": "https://github.com/JamesGeee/CVE-2021-33574 " }, { "title": "cks-notes", "trust": 0.1, "url": "https://github.com/ruzickap/cks-notes " }, { "title": "", "trust": 0.1, "url": "https://github.com/Live-Hack-CVE/CVE-2021-38604 " }, { "title": "ochacafe-s5-3", "trust": 0.1, "url": "https://github.com/oracle-japan/ochacafe-s5-3 " } ], "sources": [ { "db": "VULMON", "id": "CVE-2021-33574" }, { "db": "JVNDB", "id": "JVNDB-2021-002276" } ] }, "problemtype_data": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/problemtype_data#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "problemtype": "CWE-416", "trust": 1.1 }, { "problemtype": "Use of freed memory (CWE-416) [NVD Evaluation ]", "trust": 0.8 } ], "sources": [ { "db": "VULHUB", "id": "VHN-393646" }, { "db": "JVNDB", "id": "JVNDB-2021-002276" }, { "db": "NVD", "id": "CVE-2021-33574" } ] }, "references": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/references#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "trust": 1.8, "url": "https://security.gentoo.org/glsa/202107-07" }, { "trust": 1.7, "url": "https://security.netapp.com/advisory/ntap-20210629-0005/" }, { "trust": 1.7, "url": "https://sourceware.org/bugzilla/show_bug.cgi?id=27896" }, { "trust": 1.7, "url": "https://sourceware.org/bugzilla/show_bug.cgi?id=27896#c1" }, { "trust": 1.7, "url": "https://lists.debian.org/debian-lts-announce/2022/10/msg00021.html" }, { "trust": 1.0, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-33574" }, { "trust": 1.0, "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/kjyyimddyohtp2porlabtohyqyyrezdd/" }, { "trust": 1.0, "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/rbuuwugxvilqxvweou7n42ichpjnaeup/" }, { "trust": 0.7, "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/rbuuwugxvilqxvweou7n42ichpjnaeup/" }, { "trust": 0.7, "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/kjyyimddyohtp2porlabtohyqyyrezdd/" }, { "trust": 0.7, "url": "https://access.redhat.com/security/cve/cve-2021-27645" }, { "trust": 0.7, "url": "https://access.redhat.com/security/cve/cve-2021-33574" }, { "trust": 0.7, "url": "https://access.redhat.com/security/cve/cve-2021-35942" }, { "trust": 0.7, "url": "https://listman.redhat.com/mailman/listinfo/rhsa-announce" }, { "trust": 0.7, "url": "https://bugzilla.redhat.com/):" }, { "trust": 0.7, "url": "https://access.redhat.com/security/team/contact/" }, { "trust": 0.6, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-16135" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2021-3200" }, { "trust": 0.6, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-5827" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2020-13435" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2019-5827" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2020-24370" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2019-13751" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2019-19603" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2019-17594" }, { "trust": 0.6, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-24370" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2021-3572" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2020-12762" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2021-36086" }, { "trust": 0.6, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-13750" }, { "trust": 0.6, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-13751" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2021-22898" }, { "trust": 0.6, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-12762" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2020-16135" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2021-36084" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2021-3800" }, { "trust": 0.6, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-17594" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2021-36087" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2021-3445" }, { "trust": 0.6, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-13435" }, { "trust": 0.6, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-19603" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2021-22925" }, { "trust": 0.6, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-18218" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2021-20232" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2021-20266" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2019-20838" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2021-22876" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2021-20231" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2020-14155" }, { "trust": 0.6, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-20838" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2021-36085" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2021-33560" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2019-17595" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2021-42574" }, { "trust": 0.6, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-14155" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2021-28153" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2019-13750" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2021-3426" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2019-18218" }, { "trust": 0.6, "url": "https://access.redhat.com/security/cve/cve-2021-3580" }, { "trust": 0.6, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-17595" }, { "trust": 0.6, "url": "https://access.redhat.com/security/updates/classification/#moderate" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2022.0245" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.3905" }, { "trust": 0.6, "url": "https://www.ibm.com/support/pages/node/6526524" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2022.1071" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.4019" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.3398" }, { "trust": 0.6, "url": "https://packetstormsecurity.com/files/165862/red-hat-security-advisory-2022-0434-05.html" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2022.5140" }, { "trust": 0.6, "url": "https://vigilance.fr/vulnerability/glibc-use-after-free-via-mq-notify-35692" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.3336" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.3214" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2022.0716" }, { "trust": 0.6, "url": "https://www.cybersecurity-help.cz/vdb/sb2021092807" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2022.0394" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2022.0493" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.3935" }, { "trust": 0.6, "url": "https://packetstormsecurity.com/files/164863/red-hat-security-advisory-2021-4358-03.html" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.4229" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.4059" }, { "trust": 0.6, "url": "https://packetstormsecurity.com/files/166051/red-hat-security-advisory-2022-0580-01.html" }, { "trust": 0.6, "url": "https://www.cybersecurity-help.cz/vdb/sb2021070604" }, { "trust": 0.6, "url": "https://www.cybersecurity-help.cz/vdb/sb2021100416" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.4254" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.3785" }, { "trust": 0.6, "url": "https://packetstormsecurity.com/files/165758/red-hat-security-advisory-2022-0318-06.html" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.4095" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2021.4172" }, { "trust": 0.6, "url": "https://packetstormsecurity.com/files/163406/gentoo-linux-security-advisory-202107-07.html" }, { "trust": 0.6, "url": "https://packetstormsecurity.com/files/166308/red-hat-security-advisory-2022-0842-01.html" }, { "trust": 0.5, "url": "https://access.redhat.com/security/cve/cve-2020-14145" }, { "trust": 0.5, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-14145" }, { "trust": 0.5, "url": "https://access.redhat.com/security/cve/cve-2021-3778" }, { "trust": 0.5, "url": "https://access.redhat.com/security/cve/cve-2021-23841" }, { "trust": 0.5, "url": "https://access.redhat.com/security/cve/cve-2021-23840" }, { "trust": 0.5, "url": "https://access.redhat.com/security/cve/cve-2021-3796" }, { "trust": 0.4, "url": "https://access.redhat.com/security/cve/cve-2018-25013" }, { "trust": 0.4, "url": "https://nvd.nist.gov/vuln/detail/cve-2018-25012" }, { "trust": 0.4, "url": "https://access.redhat.com/security/cve/cve-2020-35522" }, { "trust": 0.4, "url": "https://access.redhat.com/security/cve/cve-2020-35524" }, { "trust": 0.4, "url": "https://nvd.nist.gov/vuln/detail/cve-2018-20673" }, { "trust": 0.4, "url": "https://nvd.nist.gov/vuln/detail/cve-2018-25013" }, { "trust": 0.4, "url": "https://nvd.nist.gov/vuln/detail/cve-2018-25009" }, { "trust": 0.4, "url": "https://access.redhat.com/security/cve/cve-2021-43527" }, { "trust": 0.4, "url": "https://access.redhat.com/security/cve/cve-2018-25014" }, { "trust": 0.4, "url": "https://access.redhat.com/security/cve/cve-2018-25012" }, { "trust": 0.4, "url": "https://access.redhat.com/security/cve/cve-2020-35521" }, { "trust": 0.4, "url": "https://access.redhat.com/security/cve/cve-2020-17541" }, { "trust": 0.4, "url": "https://access.redhat.com/security/cve/cve-2020-36331" }, { "trust": 0.4, "url": "https://access.redhat.com/security/cve/cve-2021-31535" }, { "trust": 0.4, "url": "https://access.redhat.com/security/cve/cve-2018-20673" }, { "trust": 0.4, "url": "https://access.redhat.com/security/cve/cve-2020-36330" }, { "trust": 0.4, "url": "https://access.redhat.com/security/cve/cve-2020-36332" }, { "trust": 0.4, "url": "https://nvd.nist.gov/vuln/detail/cve-2018-25010" }, { "trust": 0.4, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-17541" }, { "trust": 0.4, "url": "https://nvd.nist.gov/vuln/detail/cve-2018-25014" }, { "trust": 0.4, "url": "https://access.redhat.com/security/cve/cve-2021-3481" }, { "trust": 0.4, "url": "https://access.redhat.com/security/cve/cve-2018-25009" }, { "trust": 0.4, "url": "https://access.redhat.com/security/cve/cve-2018-25010" }, { "trust": 0.4, "url": "https://access.redhat.com/security/cve/cve-2020-35523" }, { "trust": 0.3, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-27645" }, { "trust": 0.3, "url": "https://access.redhat.com/security/vulnerabilities/rhsb-2021-009" }, { "trust": 0.3, "url": "https://docs.openshift.com/container-platform/4.7/logging/cluster-logging-upgrading.html" }, { "trust": 0.3, "url": "https://access.redhat.com/security/cve/cve-2021-44228" }, { "trust": 0.3, "url": "https://access.redhat.com/security/cve/cve-2021-3712" }, { "trust": 0.3, "url": "https://issues.jboss.org/):" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-24504" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-27777" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-20239" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-36158" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-35448" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-3635" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-20284" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-36386" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-0427" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-24586" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-3348" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-26140" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-3487" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-26146" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-31440" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-3732" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-0129" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-10001" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-24502" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-3564" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-0427" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-23133" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-26144" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-3679" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-36312" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-29368" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-24588" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-29646" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-29155" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-3489" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-29660" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-26139" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-28971" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2019-14615" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-26143" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-3600" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-26145" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-33200" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-29650" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-33033" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-20194" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-26147" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-31916" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-10001" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-24503" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-14615" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-24502" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-31829" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-3573" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-20197" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-26141" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-28950" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-24587" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2020-24503" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-3659" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-35524" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-35522" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-37136" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-35523" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-37137" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-21409" }, { "trust": 0.2, "url": "https://docs.openshift.com/container-platform/4.8/release_notes/ocp-4-8-release-notes.html" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-36330" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-35521" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-20317" }, { "trust": 0.2, "url": "https://access.redhat.com/security/cve/cve-2021-43267" }, { "trust": 0.2, "url": "https://access.redhat.com/articles/11258" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-22876" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-20231" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-22925" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-22898" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-20266" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-20232" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2019-25013" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-3326" }, { "trust": 0.1, "url": "https://bugs.gentoo.org." }, { "trust": 0.1, "url": "https://security.gentoo.org/" }, { "trust": 0.1, "url": "https://creativecommons.org/licenses/by-sa/2.5" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-27618" }, { "trust": 0.1, "url": "https://access.redhat.com/errata/rhsa-2021:5137" }, { "trust": 0.1, "url": "https://docs.openshift.com/container-platform/4.7/release_notes/ocp-4-7-release-notes.html" }, { "trust": 0.1, "url": "https://access.redhat.com/errata/rhsa-2021:5128" }, { "trust": 0.1, "url": "https://docs.openshift.com/container-platform/4.8/logging/cluster-logging-upgrading.html" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-36331" }, { "trust": 0.1, "url": "https://access.redhat.com/errata/rhsa-2021:5127" }, { "trust": 0.1, "url": "https://access.redhat.com/errata/rhsa-2021:4358" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-35942" }, { "trust": 0.1, "url": "https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/8.5_release_notes/" }, { "trust": 0.1, "url": "https://access.redhat.com/security/team/key/" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-36385" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-33938" }, { "trust": 0.1, "url": "https://access.redhat.com/errata/rhsa-2021:5038" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-33930" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-33928" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-37750" }, { "trust": 0.1, "url": "https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.2/html/release_notes/" }, { "trust": 0.1, "url": "https://access.redhat.com/security/updates/classification/#low" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-22947" }, { "trust": 0.1, "url": "https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.2/html-single/install/index#installing" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-22946" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-20271" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-3733" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-3795" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-36385" }, { "trust": 0.1, "url": "https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.2/html/release_notes/index" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-20271" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-20317" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-22947" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-23440" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-33929" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-22946" }, { "trust": 0.1, "url": "https://docs.openshift.com/container-platform/4.9/release_notes/ocp-4-9-release-notes.html" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-33194" }, { "trust": 0.1, "url": "https://access.redhat.com/errata/rhsa-2021:4627" }, { "trust": 0.1, "url": "https://access.redhat.com/errata/rhsa-2021:4845" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-20095" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-23841" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-28493" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-42771" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-26301" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-26301" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2021-28957" }, { "trust": 0.1, "url": "https://access.redhat.com/security/cve/cve-2020-8037" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-8037" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-23840" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2021-20095" }, { "trust": 0.1, "url": "https://nvd.nist.gov/vuln/detail/cve-2020-28493" } ], "sources": [ { "db": "VULHUB", "id": "VHN-393646" }, { "db": "JVNDB", "id": "JVNDB-2021-002276" }, { "db": "PACKETSTORM", "id": "163406" }, { "db": "PACKETSTORM", "id": "165296" }, { "db": "PACKETSTORM", "id": "165286" }, { "db": "PACKETSTORM", "id": "165287" }, { "db": "PACKETSTORM", "id": "164863" }, { "db": "PACKETSTORM", "id": "165209" }, { "db": "PACKETSTORM", "id": "164967" }, { "db": "PACKETSTORM", "id": "165096" }, { "db": "CNNVD", "id": "CNNVD-202105-1666" }, { "db": "NVD", "id": "CVE-2021-33574" } ] }, "sources": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#", "data": { "@container": "@list" } }, "data": [ { "db": "VULHUB", "id": "VHN-393646" }, { "db": "VULMON", "id": "CVE-2021-33574" }, { "db": "JVNDB", "id": "JVNDB-2021-002276" }, { "db": "PACKETSTORM", "id": "163406" }, { "db": "PACKETSTORM", "id": "165296" }, { "db": "PACKETSTORM", "id": "165286" }, { "db": "PACKETSTORM", "id": "165287" }, { "db": "PACKETSTORM", "id": "164863" }, { "db": "PACKETSTORM", "id": "165209" }, { "db": "PACKETSTORM", "id": "164967" }, { "db": "PACKETSTORM", "id": "165096" }, { "db": "CNNVD", "id": "CNNVD-202105-1666" }, { "db": "NVD", "id": "CVE-2021-33574" } ] }, "sources_release_date": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources_release_date#", "data": { "@container": "@list" } }, "data": [ { "date": "2021-05-25T00:00:00", "db": "VULHUB", "id": "VHN-393646" }, { "date": "2021-05-25T00:00:00", "db": "VULMON", "id": "CVE-2021-33574" }, { "date": "2021-08-19T00:00:00", "db": "JVNDB", "id": "JVNDB-2021-002276" }, { "date": "2021-07-06T15:43:31", "db": "PACKETSTORM", "id": "163406" }, { "date": "2021-12-15T15:27:05", "db": "PACKETSTORM", "id": "165296" }, { "date": "2021-12-15T15:20:33", "db": "PACKETSTORM", "id": "165286" }, { "date": "2021-12-15T15:20:43", "db": "PACKETSTORM", "id": "165287" }, { "date": "2021-11-10T17:08:43", "db": "PACKETSTORM", "id": "164863" }, { "date": "2021-12-09T14:50:37", "db": "PACKETSTORM", "id": "165209" }, { "date": "2021-11-15T17:25:56", "db": "PACKETSTORM", "id": "164967" }, { "date": "2021-11-29T18:12:32", "db": "PACKETSTORM", "id": "165096" }, { "date": "2021-05-25T00:00:00", "db": "CNNVD", "id": "CNNVD-202105-1666" }, { "date": "2021-05-25T22:15:10.410000", "db": "NVD", "id": "CVE-2021-33574" } ] }, "sources_update_date": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources_update_date#", "data": { "@container": "@list" } }, "data": [ { "date": "2022-11-08T00:00:00", "db": "VULHUB", "id": "VHN-393646" }, { "date": "2023-11-07T00:00:00", "db": "VULMON", "id": "CVE-2021-33574" }, { "date": "2021-08-19T01:48:00", "db": "JVNDB", "id": "JVNDB-2021-002276" }, { "date": "2022-10-18T00:00:00", "db": "CNNVD", "id": "CNNVD-202105-1666" }, { "date": "2023-11-07T03:35:52.810000", "db": "NVD", "id": "CVE-2021-33574" } ] }, "threat_type": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/threat_type#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "remote", "sources": [ { "db": "CNNVD", "id": "CNNVD-202105-1666" } ], "trust": 0.6 }, "title": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/title#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "GNU\u00a0C\u00a0Library\u00a0 Vulnerabilities in the use of freed memory", "sources": [ { "db": "JVNDB", "id": "JVNDB-2021-002276" } ], "trust": 0.8 }, "type": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/type#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "resource management error", "sources": [ { "db": "CNNVD", "id": "CNNVD-202105-1666" } ], "trust": 0.6 } }
var-201606-0391
Vulnerability from variot
Stack-based buffer overflow in the clntudp_call function in sunrpc/clnt_udp.c in the GNU C Library (aka glibc or libc6) allows remote servers to cause a denial of service (crash) or possibly unspecified other impact via a flood of crafted ICMP and UDP packets. GNU glibc is prone to a remote denial-of-service vulnerability. Successful exploits may allow an attacker to crash the application or to consume excessive memory resources, resulting in a denial-of-service condition. Due to the nature of this issue arbitrary code execution may be possible, but this has not been confirmed. GNU glibc 2.24 is vulnerable; other versions may also be affected. Note: libtirpc is also affected. (CVE-2016-4429)
It was discovered that libtirpc incorrectly handled certain inputs. (CVE-2018-14622)
It was discovered that libtirpc incorrectly handled certain strings.
Ubuntu Security Notice USN-3239-2 March 21, 2017
eglibc, glibc regression
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 16.04 LTS
- Ubuntu 14.04 LTS
- Ubuntu 12.04 LTS
Summary:
USN-3239-1 introduced a regression in the GNU C Library.
Software Description: - glibc: GNU C Library - eglibc: GNU C Library
Details:
USN-3239-1 fixed vulnerabilities in the GNU C Library. Unfortunately, the fix for CVE-2015-5180 introduced an internal ABI change within the resolver library. This update reverts the change. We apologize for the inconvenience.
Please note that long-running services that were restarted to compensate for the USN-3239-1 update may need to be restarted again.
Original advisory details:
It was discovered that the GNU C Library incorrectly handled the strxfrm() function. This issue only affected Ubuntu 12.04 LTS and Ubuntu 14.04 LTS. (CVE-2015-8982)
It was discovered that an integer overflow existed in the _IO_wstr_overflow() function of the GNU C Library. This issue only affected Ubuntu 12.04 LTS and Ubuntu 14.04 LTS. (CVE-2015-8983)
It was discovered that the fnmatch() function in the GNU C Library did not properly handle certain malformed patterns. An attacker could use this to cause a denial of service. This issue only affected Ubuntu 12.04 LTS and Ubuntu 14.04 LTS. (CVE-2015-8984)
Alexander Cherepanov discovered a stack-based buffer overflow in the glob implementation of the GNU C Library. An attacker could use this to specially craft a directory layout and cause a denial of service. (CVE-2016-1234)
Florian Weimer discovered a NULL pointer dereference in the DNS resolver of the GNU C Library. An attacker could use this to cause a denial of service. (CVE-2015-5180)
Michael Petlan discovered an unbounded stack allocation in the getaddrinfo() function of the GNU C Library. An attacker could use this to cause a denial of service. (CVE-2016-3706)
Aldy Hernandez discovered an unbounded stack allocation in the sunrpc implementation in the GNU C Library. An attacker could use this to cause a denial of service. (CVE-2016-4429)
Tim Ruehsen discovered that the getaddrinfo() implementation in the GNU C Library did not properly track memory allocations. An attacker could use this to cause a denial of service. This issue only affected Ubuntu 16.04 LTS. (CVE-2016-5417)
Andreas Schwab discovered that the GNU C Library on ARM 32-bit platforms did not properly set up execution contexts. An attacker could use this to cause a denial of service. (CVE-2016-6323)
Update instructions:
The problem can be corrected by updating your system to the following package versions:
Ubuntu 16.04 LTS: libc6 2.23-0ubuntu7
Ubuntu 14.04 LTS: libc6 2.19-0ubuntu6.11
Ubuntu 12.04 LTS: libc6 2.15-0ubuntu10.17
After a standard system update you need to reboot your computer to make all the necessary changes.
References: http://www.ubuntu.com/usn/usn-3239-2 http://www.ubuntu.com/usn/usn-3239-1 https://bugs.launchpad.net/bugs/1674532
Package Information: https://launchpad.net/ubuntu/+source/glibc/2.23-0ubuntu7 https://launchpad.net/ubuntu/+source/eglibc/2.19-0ubuntu6.11 https://launchpad.net/ubuntu/+source/eglibc/2.15-0ubuntu10.17
Show details on source website{ "@context": { "@vocab": "https://www.variotdbs.pl/ref/VARIoTentry#", "affected_products": { "@id": "https://www.variotdbs.pl/ref/affected_products" }, "configurations": { "@id": "https://www.variotdbs.pl/ref/configurations" }, "credits": { "@id": "https://www.variotdbs.pl/ref/credits" }, "cvss": { "@id": "https://www.variotdbs.pl/ref/cvss/" }, "description": { "@id": "https://www.variotdbs.pl/ref/description/" }, "exploit_availability": { "@id": "https://www.variotdbs.pl/ref/exploit_availability/" }, "external_ids": { "@id": "https://www.variotdbs.pl/ref/external_ids/" }, "iot": { "@id": "https://www.variotdbs.pl/ref/iot/" }, "iot_taxonomy": { "@id": "https://www.variotdbs.pl/ref/iot_taxonomy/" }, "patch": { "@id": "https://www.variotdbs.pl/ref/patch/" }, "problemtype_data": { "@id": "https://www.variotdbs.pl/ref/problemtype_data/" }, "references": { "@id": "https://www.variotdbs.pl/ref/references/" }, "sources": { "@id": "https://www.variotdbs.pl/ref/sources/" }, "sources_release_date": { "@id": "https://www.variotdbs.pl/ref/sources_release_date/" }, "sources_update_date": { "@id": "https://www.variotdbs.pl/ref/sources_update_date/" }, "threat_type": { "@id": "https://www.variotdbs.pl/ref/threat_type/" }, "title": { "@id": "https://www.variotdbs.pl/ref/title/" }, "type": { "@id": "https://www.variotdbs.pl/ref/type/" } }, "@id": "https://www.variotdbs.pl/vuln/VAR-201606-0391", "affected_products": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/affected_products#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" }, "@id": "https://www.variotdbs.pl/ref/sources" } }, "data": [ { "model": "opensuse", "scope": "eq", "trust": 1.8, "vendor": "opensuse", "version": "13.2" }, { "model": "leap", "scope": "eq", "trust": 1.0, "vendor": "opensuse", "version": "42.1" }, { "model": "glibc", "scope": "lt", "trust": 1.0, "vendor": "gnu", "version": "2.24" }, { "model": "ubuntu linux", "scope": "eq", "trust": 1.0, "vendor": "canonical", "version": "14.04" }, { "model": "ubuntu linux", "scope": "eq", "trust": 1.0, "vendor": "canonical", "version": "18.04" }, { "model": "ubuntu linux", "scope": "eq", "trust": 1.0, "vendor": "canonical", "version": "16.04" }, { "model": "ubuntu linux", "scope": "eq", "trust": 1.0, "vendor": "canonical", "version": "12.04" }, { "model": "c library", "scope": null, "trust": 0.8, "vendor": "gnu", "version": null }, { "model": "glibc", "scope": null, "trust": 0.6, "vendor": "gnu", "version": null }, { "model": "big-ip afm hf6", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6" }, { "model": "security network controller 1.0.3361m", "scope": null, "trust": 0.3, "vendor": "ibm", "version": null }, { "model": "big-ip gtm hf9", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip analytics hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0.0" }, { "model": "big-ip analytics build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.110.104.180" }, { "model": "big-ip psm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip aam", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5" }, { "model": "big-ip aam build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.40.1.256" }, { "model": "big-ip afm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.1" }, { "model": "big-ip link controller", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.4" }, { "model": "big-ip psm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.4" }, { "model": "big-ip asm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.0" }, { "model": "big-ip gtm hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip analytics hf7", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5" }, { "model": "big-ip apm hf4", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6" }, { "model": "big-ip afm hf6", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "security network controller", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "1.0.1209" }, { "model": "big-ip link controller", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.1" }, { "model": "big-ip pem", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.4" }, { "model": "big-ip asm hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0.0" }, { "model": "big-ip link controller build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.01.14.628" }, { "model": "big-ip apm hf8", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip ltm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.1" }, { "model": "big-ip afm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.1.0" }, { "model": "big-ip afm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.0" }, { "model": "big-ip link controller hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0" }, { "model": "big-ip aam hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.4" }, { "model": "big-ip link controller hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-iq device", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.5" }, { "model": "security network controller", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "1.0.3361" }, { "model": "big-ip pem hf6", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6" }, { "model": "security proventia network active bypass", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "2.13-34" }, { "model": "big-iq device", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.2" }, { "model": "big-ip pem hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "big-ip apm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.0" }, { "model": "glibc", "scope": "eq", "trust": 0.3, "vendor": "gnu", "version": "2.24" }, { "model": "big-ip asm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0" }, { "model": "big-ip asm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "security network controller", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "1.0.3394" }, { "model": "big-ip afm hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip link controller hf5", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.0" }, { "model": "big-ip apm hf4", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip apm hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.1" }, { "model": "big-ip analytics", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.4" }, { "model": "big-iq device", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.4" }, { "model": "big-ip afm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5" }, { "model": "big-ip aam hf8", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip link controller", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "big-ip aam hf4", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip gtm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip afm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0" }, { "model": "big-ip afm build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.01.14.628" }, { "model": "big-ip asm hf3", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip analytics hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0.0" }, { "model": "big-ip apm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.2" }, { "model": "security proventia network active bypass", "scope": "ne", "trust": 0.3, "vendor": "ibm", "version": "3.30.7-23" }, { "model": "security proventia network active bypass", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "2.16-37" }, { "model": "big-ip psm hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.1" }, { "model": "big-ip analytics", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.1" }, { "model": "big-ip link controller", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.2.1" }, { "model": "big-ip afm hf8", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip asm hf10", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip gtm hf10", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip ltm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "security virtual server protection for vmware", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "1.1.0.1" }, { "model": "big-ip pem hf9", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip gtm hf6", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6" }, { "model": "big-ip apm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.1" }, { "model": "big-ip gtm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.2" }, { "model": "security proventia network active bypass", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "3.25-57" }, { "model": "big-ip ltm hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.1" }, { "model": "security proventia network active bypass", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "2.18-43" }, { "model": "big-ip webaccelerator hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.1" }, { "model": "big-ip ltm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.1" }, { "model": "big-ip edge gateway", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.3" }, { "model": "big-ip afm hf5", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.0" }, { "model": "big-ip link controller hf9", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip link controller hf6", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6" }, { "model": "big-ip apm hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "big-ip link controller hf8", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip afm build 685-hf10", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip gtm hf6", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip gtm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.2" }, { "model": "big-ip asm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.40" }, { "model": "big-iq device hf3", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.4" }, { "model": "arx", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "6.4" }, { "model": "security proventia network active bypass", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "2.11-28" }, { "model": "big-ip analytics", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.2.1" }, { "model": "big-iq security", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.5" }, { "model": "big-ip link controller hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.1" }, { "model": "big-ip dns build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.01.14.628" }, { "model": "big-ip afm build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.110.104.180" }, { "model": "big-ip pem hf8", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "security network controller 1.0.3350m", "scope": null, "trust": 0.3, "vendor": "ibm", "version": null }, { "model": "big-ip dns", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0" }, { "model": "big-ip edge gateway 10.2.3-hf1", "scope": null, "trust": 0.3, "vendor": "f5", "version": null }, { "model": "arx", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "6.3" }, { "model": "big-ip link controller hf6", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip asm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.4" }, { "model": "big-ip aam hf10", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip ltm hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0.0" }, { "model": "big-iq security", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.4" }, { "model": "big-ip pem", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.1.0" }, { "model": "big-ip ltm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0" }, { "model": "big-ip afm hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.4" }, { "model": "big-ip ltm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip aam hf6", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6" }, { "model": "big-ip edge gateway", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.4" }, { "model": "big-ip apm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.1" }, { "model": "big-ip wom", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.2" }, { "model": "big-ip asm hf5", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.0" }, { "model": "security proventia network active bypass", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "3.30.0-13" }, { "model": "big-ip afm hf3", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0.0" }, { "model": "big-ip pem hf3", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0" }, { "model": "arx", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "6.2" }, { "model": "big-ip asm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.1" }, { "model": "big-ip aam", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "big-ip analytics hf5", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.0" }, { "model": "big-ip aam build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.66.204.442" }, { "model": "big-ip asm hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0.0" }, { "model": "big-ip analytics hf3", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip aam", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.1" }, { "model": "big-ip link controller hf10", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip gtm hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "big-ip gtm hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.1" }, { "model": "big-ip gtm build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.110.104.180" }, { "model": "big-ip aam hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0.0" }, { "model": "big-ip pem", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5" }, { "model": "big-ip apm hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip gtm hf5", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.0" }, { "model": "big-ip apm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.0" }, { "model": "big-ip analytics hf6", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6" }, { "model": "big-ip apm hf10", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip wom", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.2.1" }, { "model": "security proventia network active bypass", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "2.15-36" }, { "model": "big-ip aam hf6", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip gtm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.3" }, { "model": "big-ip link controller hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "security network controller 1.0.3387m", "scope": null, "trust": 0.3, "vendor": "ibm", "version": null }, { "model": "big-ip asm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "security network controller 1.0.3379m", "scope": null, "trust": 0.3, "vendor": "ibm", "version": null }, { "model": "big-iq device", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.3" }, { "model": "big-ip apm hf5", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6" }, { "model": "big-ip apm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0" }, { "model": "big-ip apm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip analytics hf6", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip aam", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.0" }, { "model": "big-ip afm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "big-ip analytics hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "big-ip gtm hf4", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.0" }, { "model": "big-ip apm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.4" }, { "model": "big-ip aam", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0" }, { "model": "big-ip gtm hf8", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip pem", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip aam", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip gtm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5" }, { "model": "big-ip afm hf9", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip webaccelerator", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.2" }, { "model": "big-ip link controller hf3", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0" }, { "model": "big-ip aam hf3", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip link controller hf3", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip apm hf9", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip asm hf4", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.0" }, { "model": "big-ip link controller", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.2" }, { "model": "security network controller", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "1.0.1768" }, { "model": "android", "scope": "eq", "trust": 0.3, "vendor": "google", "version": "0" }, { "model": "big-ip edge gateway", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.1" }, { "model": "big-ip apm hf5", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip asm hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "websafe", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "1.0" }, { "model": "security proventia network active bypass", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "1.0.2919" }, { "model": "big-ip link controller hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip gtm hf4", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip ltm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.4" }, { "model": "big-ip asm hf3", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0.0" }, { "model": "big-ip aam hf9", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "mobilesafe", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "1.0" }, { "model": "security proventia network active bypass", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "3.30.2-9" }, { "model": "big-ip webaccelerator", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.2.1" }, { "model": "big-ip analytics", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip asm hf8", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-iq cloud hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.4" }, { "model": "big-ip asm build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.40.1.256" }, { "model": "big-ip ltm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.1" }, { "model": "big-ip link controller", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.2" }, { "model": "big-ip apm hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.4" }, { "model": "linux lts amd64", "scope": "eq", "trust": 0.3, "vendor": "ubuntu", "version": "12.04" }, { "model": "big-ip apm build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.110.104.180" }, { "model": "big-ip aam build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.01.14.628" }, { "model": "big-ip afm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip analytics hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip analytics", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.2" }, { "model": "big-ip edge gateway hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.1" }, { "model": "big-ip ltm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.2" }, { "model": "big-ip gtm hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip apm hf6", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6" }, { "model": "big-ip gtm hf9", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-iq security", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.3" }, { "model": "security proventia network active bypass", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "3.29-9" }, { "model": "big-ip link controller hf5", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "security network controller", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "1.0.3387" }, { "model": "big-ip psm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-iq cloud hf3", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.4" }, { "model": "big-ip asm hf6", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6" }, { "model": "big-ip ltm hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0.0" }, { "model": "security network controller 1.0.3352m", "scope": null, "trust": 0.3, "vendor": "ibm", "version": null }, { "model": "big-ip asm hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip asm hf9", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip afm hf4", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.0" }, { "model": "big-ip apm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.4" }, { "model": "big-ip ltm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.2.1" }, { "model": "big-ip apm hf8", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip afm hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0.0" }, { "model": "big-ip aam", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.4" }, { "model": "big-ip apm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.1" }, { "model": "big-ip aam hf5", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.0" }, { "model": "big-ip asm hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.1" }, { "model": "big-ip apm hf6", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip gtm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.1" }, { "model": "big-ip analytics hf4", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6" }, { "model": "big-ip link controller", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.3" }, { "model": "big-ip asm hf6", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip afm hf4", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip link controller hf4", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6" }, { "model": "big-ip pem", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.1" }, { "model": "big-ip afm hf10", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip aam hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0.0" }, { "model": "big-ip asm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip afm hf5", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip analytics build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.40.1.256" }, { "model": "big-ip aam", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.1" }, { "model": "big-ip analytics hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip link controller hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.4" }, { "model": "big-ip link controller", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.1.0" }, { "model": "big-ip aam build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.110.104.180" }, { "model": "big-ip apm hf3", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6" }, { "model": "big-ip pem hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.4" }, { "model": "big-ip aam hf5", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "security virtual server protection for vmware", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "1.1" }, { "model": "big-ip psm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.2" }, { "model": "big-ip apm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "big-iq centralized management", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.6" }, { "model": "big-ip analytics hf4", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip analytics hf10", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip ltm hf3", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0.0" }, { "model": "big-ip pem", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.0" }, { "model": "big-ip link controller hf7", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5" }, { "model": "big-ip analytics build 685-hf10", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip analytics", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.1" }, { "model": "big-ip link controller hf4", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip pem hf10", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip link controller", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5" }, { "model": "big-ip apm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.2.1" }, { "model": "big-ip afm hf8", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip afm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.4" }, { "model": "big-ip analytics hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.4" }, { "model": "big-ip apm hf3", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip aam hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "big-ip gtm hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.4" }, { "model": "big-ip analytics hf8", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip gtm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.1" }, { "model": "big-ip analytics", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.1.0" }, { "model": "big-ip analytics", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.0" }, { "model": "big-ip afm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.1" }, { "model": "big-ip pem", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0" }, { "model": "big-ip link controller hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "big-iq cloud", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.0" }, { "model": "big-ip asm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.2" }, { "model": "big-ip asm hf5", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip link controller hf9", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip pem hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "big-ip dns hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0.0" }, { "model": "big-ip analytics hf5", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip apm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.0" }, { "model": "big-ip gtm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.0" }, { "model": "big-ip analytics", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5" }, { "model": "big-ip psm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.3" }, { "model": "big-ip asm build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.66.204.442" }, { "model": "big-ip gtm hf5", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip asm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.2.1" }, { "model": "big-ip analytics", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0" }, { "model": "security network controller 1.0.3394m", "scope": null, "trust": 0.3, "vendor": "ibm", "version": null }, { "model": "security network controller 1.0.3381m", "scope": null, "trust": 0.3, "vendor": "ibm", "version": null }, { "model": "big-iq cloud", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.2" }, { "model": "security proventia network active bypass", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "1.0" }, { "model": "linux lts i386", "scope": "eq", "trust": 0.3, "vendor": "ubuntu", "version": "12.04" }, { "model": "big-ip wom", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.3" }, { "model": "big-iq centralized management", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "5.0" }, { "model": "big-ip afm hf3", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip link controller build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.40.1.256" }, { "model": "big-ip gtm hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "big-ip aam hf10", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip link controller hf8", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.1" }, { "model": "big-iq adc", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.5" }, { "model": "big-ip asm hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip aam hf8", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip ltm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip gtm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-iq cloud", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.1" }, { "model": "big-ip aam hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip analytics hf9", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip afm hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0.0" }, { "model": "big-ip gtm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.4" }, { "model": "security proventia network active bypass", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "3.18-49" }, { "model": "big-ip asm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.3" }, { "model": "big-ip gtm hf3", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip link controller hf10", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip asm hf10", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "security proventia network active bypass", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "3.13-41" }, { "model": "big-ip gtm hf10", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip link controller", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.1" }, { "model": "big-ip afm build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.40.1.256" }, { "model": "big-ip ltm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.2" }, { "model": "big-ip apm hf10", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip asm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.1.0" }, { "model": "big-ip psm hf9", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip asm hf4", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip wom", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.4" }, { "model": "big-ip dns hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0" }, { "model": "big-ip analytics hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "security network controller", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "1.0.3381" }, { "model": "big-ip analytics build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.66.204.442" }, { "model": "big-ip aam hf4", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.0" }, { "model": "big-ip link controller hf8", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip edge gateway", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.2" }, { "model": "big-iq cloud and orchestration", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "1.0" }, { "model": "big-ip apm hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.2" }, { "model": "big-ip analytics hf8", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.1" }, { "model": "big-ip asm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5" }, { "model": "big-ip webaccelerator", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.3" }, { "model": "big-ip pem", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.1" }, { "model": "big-ip gtm build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.40.1.256" }, { "model": "big-ip aam build 685-hf10", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip gtm build 685-hf10", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip edge gateway", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.2.1" }, { "model": "big-ip apm hf9", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip link controller", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.1" }, { "model": "big-ip asm build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.01.14.628" }, { "model": "big-ip afm hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "big-ip apm hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "big-ip asm hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.4" }, { "model": "big-ip pem", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "big-ip gtm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.4" }, { "model": "security network controller", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "1.0.3376" }, { "model": "libtirpc", "scope": "eq", "trust": 0.3, "vendor": "redhat", "version": "0" }, { "model": "security proventia network active bypass", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "2.18-42" }, { "model": "big-ip aam", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.2" }, { "model": "big-ip aam hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "big-ip apm build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.66.204.442" }, { "model": "big-ip pem hf5", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.0" }, { "model": "big-ip analytics hf8", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip link controller", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6" }, { "model": "big-ip gtm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.1" }, { "model": "big-ip apm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.2" }, { "model": "big-ip webaccelerator", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.4" }, { "model": "big-ip psm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.1" }, { "model": "big-ip asm build 685-hf10", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip ltm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.3" }, { "model": "big-ip analytics hf3", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0.0" }, { "model": "big-iq security", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.0" }, { "model": "big-ip psm hf8", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip pem hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0" }, { "model": "big-ip dns", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.1.0" }, { "model": "big-ip analytics", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "big-ip wom", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.1" }, { "model": "big-ip apm hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0.0" }, { "model": "security proventia network active bypass", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "1.0.1876" }, { "model": "big-ip asm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.2" }, { "model": "big-ip ltm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.1.0" }, { "model": "big-ip ltm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.0" }, { "model": "big-iq cloud", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.3" }, { "model": "big-ip link controller", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0" }, { "model": "big-ip wom hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.1" }, { "model": "big-ip link controller", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip link controller build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.66.204.442" }, { "model": "big-ip asm hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "big-ip psm hf10", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-iq security", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.2" }, { "model": "big-ip gtm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "security proventia network active bypass", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "3.30.4-12" }, { "model": "big-ip link controller", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.4" }, { "model": "big-ip afm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.2" }, { "model": "big-ip afm hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip asm hf9", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip dns hf3", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0" }, { "model": "iworkflow", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "2.0" }, { "model": "big-ip asm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.1" }, { "model": "big-ip apm hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip asm build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.110.104.180" }, { "model": "big-ip gtm hf8", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip pem", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip ltm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5" }, { "model": "big-ip gtm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.2.1" }, { "model": "big-ip analytics build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.01.14.628" }, { "model": "big-ip apm build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.40.1.256" }, { "model": "big-ip afm hf9", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "security network controller 1.0.3376m", "scope": null, "trust": 0.3, "vendor": "ibm", "version": null }, { "model": "big-ip aam hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-iq security", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.1" }, { "model": "big-ip analytics hf9", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "security network controller", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "1.0.3379" }, { "model": "big-ip ltm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.4" }, { "model": "security proventia network active bypass", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "3.0" }, { "model": "big-ip apm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.3" }, { "model": "big-ip afm build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.66.204.442" }, { "model": "big-ip pem hf4", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.0" }, { "model": "big-ip aam hf3", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0.0" }, { "model": "big-ip afm hf10", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-iq cloud", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.5" }, { "model": "big-ip aam hf9", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "enterprise manager", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "3.1.1" }, { "model": "big-ip analytics", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip asm hf8", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip apm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.1.0" }, { "model": "big-ip link controller hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0.0" }, { "model": "big-iq security hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.4" }, { "model": "big-ip webaccelerator", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "10.2.1" }, { "model": "big-ip apm build 685-hf10", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4.1" }, { "model": "big-ip pem hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.0.0" }, { "model": "big-iq cloud", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.4" }, { "model": "big-ip analytics hf10", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.4" }, { "model": "big-ip aam", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.1.0" }, { "model": "big-ip aam", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.6.0" }, { "model": "security virtual server protection for vmware", "scope": "eq", "trust": 0.3, "vendor": "ibm", "version": "1.1.1" }, { "model": "big-iq device hf2", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "4.4" }, { "model": "big-ip gtm build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.66.204.442" }, { "model": "big-ip afm hf1", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.3" }, { "model": "big-ip asm", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "11.5.1" }, { "model": "big-ip apm build", "scope": "eq", "trust": 0.3, "vendor": "f5", "version": "12.01.14.628" } ], "sources": [ { "db": "BID", "id": "90737" }, { "db": "JVNDB", "id": "JVNDB-2016-003093" }, { "db": "CNNVD", "id": "CNNVD-201606-230" }, { "db": "NVD", "id": "CVE-2016-4429" } ] }, "configurations": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/configurations#", "children": { "@container": "@list" }, "cpe_match": { "@container": "@list" }, "data": { "@container": "@list" }, "nodes": { "@container": "@list" } }, "data": [ { "CVE_data_version": "4.0", "nodes": [ { "cpe_match": [ { "cpe22Uri": "cpe:/a:gnu:glibc", "vulnerable": true }, { "cpe22Uri": "cpe:/o:opensuse_project:opensuse", "vulnerable": true } ], "operator": "OR" } ] } ], "sources": [ { "db": "JVNDB", "id": "JVNDB-2016-003093" } ] }, "credits": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/credits#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "The vendor reported these issues.", "sources": [ { "db": "CNNVD", "id": "CNNVD-201606-230" } ], "trust": 0.6 }, "cve": "CVE-2016-4429", "cvss": { "@context": { "cvssV2": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/cvss/cvssV2#" }, "@id": "https://www.variotdbs.pl/ref/cvss/cvssV2" }, "cvssV3": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/cvss/cvssV3#" }, "@id": "https://www.variotdbs.pl/ref/cvss/cvssV3/" }, "severity": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/cvss/severity#" }, "@id": "https://www.variotdbs.pl/ref/cvss/severity" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" }, "@id": "https://www.variotdbs.pl/ref/sources" } }, "data": [ { "cvssV2": [ { "accessComplexity": "MEDIUM", "accessVector": "NETWORK", "authentication": "NONE", "author": "nvd@nist.gov", "availabilityImpact": "PARTIAL", "baseScore": 4.3, "confidentialityImpact": "NONE", "exploitabilityScore": 8.6, "id": "CVE-2016-4429", "impactScore": 2.9, "integrityImpact": "NONE", "severity": "MEDIUM", "trust": 1.1, "vectorString": "AV:N/AC:M/Au:N/C:N/I:N/A:P", "version": "2.0" }, { "acInsufInfo": null, "accessComplexity": "Low", "accessVector": "Network", "authentication": "None", "author": "NVD", "availabilityImpact": "Partial", "baseScore": 7.5, "confidentialityImpact": "Partial", "exploitabilityScore": null, "id": "CVE-2016-4429", "impactScore": null, "integrityImpact": "Partial", "obtainAllPrivilege": null, "obtainOtherPrivilege": null, "obtainUserPrivilege": null, "severity": "High", "trust": 0.8, "userInteractionRequired": null, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0" } ], "cvssV3": [ { "attackComplexity": "HIGH", "attackVector": "NETWORK", "author": "nvd@nist.gov", "availabilityImpact": "HIGH", "baseScore": 5.9, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "exploitabilityScore": 2.2, "id": "CVE-2016-4429", "impactScore": 3.6, "integrityImpact": "NONE", "privilegesRequired": "NONE", "scope": "UNCHANGED", "trust": 1.0, "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H", "version": "3.1" }, { "attackComplexity": "Low", "attackVector": "Network", "author": "NVD", "availabilityImpact": "High", "baseScore": 9.8, "baseSeverity": "Critical", "confidentialityImpact": "High", "exploitabilityScore": null, "id": "CVE-2016-4429", "impactScore": null, "integrityImpact": "High", "privilegesRequired": "None", "scope": "Unchanged", "trust": 0.8, "userInteraction": "None", "vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.0" } ], "severity": [ { "author": "nvd@nist.gov", "id": "CVE-2016-4429", "trust": 1.0, "value": "MEDIUM" }, { "author": "NVD", "id": "CVE-2016-4429", "trust": 0.8, "value": "Critical" }, { "author": "CNNVD", "id": "CNNVD-201606-230", "trust": 0.6, "value": "MEDIUM" }, { "author": "VULMON", "id": "CVE-2016-4429", "trust": 0.1, "value": "MEDIUM" } ] } ], "sources": [ { "db": "VULMON", "id": "CVE-2016-4429" }, { "db": "JVNDB", "id": "JVNDB-2016-003093" }, { "db": "CNNVD", "id": "CNNVD-201606-230" }, { "db": "NVD", "id": "CVE-2016-4429" } ] }, "description": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/description#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "Stack-based buffer overflow in the clntudp_call function in sunrpc/clnt_udp.c in the GNU C Library (aka glibc or libc6) allows remote servers to cause a denial of service (crash) or possibly unspecified other impact via a flood of crafted ICMP and UDP packets. GNU glibc is prone to a remote denial-of-service vulnerability. \nSuccessful exploits may allow an attacker to crash the application or to consume excessive memory resources, resulting in a denial-of-service condition. Due to the nature of this issue arbitrary code execution may be possible, but this has not been confirmed. \nGNU glibc 2.24 is vulnerable; other versions may also be affected. \nNote: libtirpc is also affected. (CVE-2016-4429)\n\nIt was discovered that libtirpc incorrectly handled certain inputs. \n(CVE-2018-14622)\n\nIt was discovered that libtirpc incorrectly handled certain strings. \n===========================================================================\nUbuntu Security Notice USN-3239-2\nMarch 21, 2017\n\neglibc, glibc regression\n===========================================================================\n\nA security issue affects these releases of Ubuntu and its derivatives:\n\n- Ubuntu 16.04 LTS\n- Ubuntu 14.04 LTS\n- Ubuntu 12.04 LTS\n\nSummary:\n\nUSN-3239-1 introduced a regression in the GNU C Library. \n\nSoftware Description:\n- glibc: GNU C Library\n- eglibc: GNU C Library\n\nDetails:\n\nUSN-3239-1 fixed vulnerabilities in the GNU C Library. Unfortunately,\nthe fix for CVE-2015-5180 introduced an internal ABI change within\nthe resolver library. This update reverts the change. We apologize\nfor the inconvenience. \n\nPlease note that long-running services that were restarted to compensate\nfor the USN-3239-1 update may need to be restarted again. \n\nOriginal advisory details:\n\n It was discovered that the GNU C Library incorrectly handled the\n strxfrm() function. This issue only affected\n Ubuntu 12.04 LTS and Ubuntu 14.04 LTS. (CVE-2015-8982)\n\n It was discovered that an integer overflow existed in the\n _IO_wstr_overflow() function of the GNU C Library. This issue only affected Ubuntu 12.04 LTS and Ubuntu 14.04\n LTS. (CVE-2015-8983)\n\n It was discovered that the fnmatch() function in the GNU C Library\n did not properly handle certain malformed patterns. An attacker could\n use this to cause a denial of service. This issue only affected Ubuntu\n 12.04 LTS and Ubuntu 14.04 LTS. (CVE-2015-8984)\n\n Alexander Cherepanov discovered a stack-based buffer overflow in the\n glob implementation of the GNU C Library. An attacker could use this\n to specially craft a directory layout and cause a denial of service. \n (CVE-2016-1234)\n\n Florian Weimer discovered a NULL pointer dereference in the DNS\n resolver of the GNU C Library. An attacker could use this to cause\n a denial of service. (CVE-2015-5180)\n\n Michael Petlan discovered an unbounded stack allocation in the\n getaddrinfo() function of the GNU C Library. An attacker could use\n this to cause a denial of service. (CVE-2016-3706)\n\n Aldy Hernandez discovered an unbounded stack allocation in the sunrpc\n implementation in the GNU C Library. An attacker could use this to\n cause a denial of service. (CVE-2016-4429)\n\n Tim Ruehsen discovered that the getaddrinfo() implementation in the\n GNU C Library did not properly track memory allocations. An attacker\n could use this to cause a denial of service. This issue only affected\n Ubuntu 16.04 LTS. (CVE-2016-5417)\n\n Andreas Schwab discovered that the GNU C Library on ARM 32-bit\n platforms did not properly set up execution contexts. An attacker\n could use this to cause a denial of service. (CVE-2016-6323)\n\nUpdate instructions:\n\nThe problem can be corrected by updating your system to the following\npackage versions:\n\nUbuntu 16.04 LTS:\n libc6 2.23-0ubuntu7\n\nUbuntu 14.04 LTS:\n libc6 2.19-0ubuntu6.11\n\nUbuntu 12.04 LTS:\n libc6 2.15-0ubuntu10.17\n\nAfter a standard system update you need to reboot your computer to make\nall the necessary changes. \n\nReferences:\n http://www.ubuntu.com/usn/usn-3239-2\n http://www.ubuntu.com/usn/usn-3239-1\n https://bugs.launchpad.net/bugs/1674532\n\nPackage Information:\n https://launchpad.net/ubuntu/+source/glibc/2.23-0ubuntu7\n https://launchpad.net/ubuntu/+source/eglibc/2.19-0ubuntu6.11\n https://launchpad.net/ubuntu/+source/eglibc/2.15-0ubuntu10.17\n\n\n", "sources": [ { "db": "NVD", "id": "CVE-2016-4429" }, { "db": "JVNDB", "id": "JVNDB-2016-003093" }, { "db": "BID", "id": "90737" }, { "db": "VULMON", "id": "CVE-2016-4429" }, { "db": "PACKETSTORM", "id": "149244" }, { "db": "PACKETSTORM", "id": "141812" }, { "db": "PACKETSTORM", "id": "149243" }, { "db": "PACKETSTORM", "id": "141758" }, { "db": "PACKETSTORM", "id": "141749" } ], "trust": 2.43 }, "external_ids": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/external_ids#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "db": "NVD", "id": "CVE-2016-4429", "trust": 3.3 }, { "db": "BID", "id": "102073", "trust": 1.7 }, { "db": "JVNDB", "id": "JVNDB-2016-003093", "trust": 0.8 }, { "db": "AUSCERT", "id": "ESB-2020.2223", "trust": 0.6 }, { "db": "CNNVD", "id": "CNNVD-201606-230", "trust": 0.6 }, { "db": "BID", "id": "90737", "trust": 0.3 }, { "db": "VULMON", "id": "CVE-2016-4429", "trust": 0.1 }, { "db": "PACKETSTORM", "id": "149244", "trust": 0.1 }, { "db": "PACKETSTORM", "id": "141812", "trust": 0.1 }, { "db": "PACKETSTORM", "id": "149243", "trust": 0.1 }, { "db": "PACKETSTORM", "id": "141758", "trust": 0.1 }, { "db": "PACKETSTORM", "id": "141749", "trust": 0.1 } ], "sources": [ { "db": "VULMON", "id": "CVE-2016-4429" }, { "db": "BID", "id": "90737" }, { "db": "JVNDB", "id": "JVNDB-2016-003093" }, { "db": "PACKETSTORM", "id": "149244" }, { "db": "PACKETSTORM", "id": "141812" }, { "db": "PACKETSTORM", "id": "149243" }, { "db": "PACKETSTORM", "id": "141758" }, { "db": "PACKETSTORM", "id": "141749" }, { "db": "CNNVD", "id": "CNNVD-201606-230" }, { "db": "NVD", "id": "CVE-2016-4429" } ] }, "id": "VAR-201606-0391", "iot": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/iot#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": true, "sources": [ { "db": "VARIoT devices database", "id": null } ], "trust": 0.460834645 }, "last_update_date": "2024-08-14T13:15:31.347000Z", "patch": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/patch#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "title": "openSUSE-SU-2016:1527", "trust": 0.8, "url": "https://lists.opensuse.org/opensuse-updates/2016-06/msg00030.html" }, { "title": "Bug 20112", "trust": 0.8, "url": "https://sourceware.org/bugzilla/show_bug.cgi?id=20112" }, { "title": "CVE-2016-4429: sunrpc: Do not use alloca in clntudp_call [BZ #20112]", "trust": 0.8, "url": "https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=bc779a1a5b3035133024b21e2f339fe4219fb11c" }, { "title": "GNU C Library Fixes for stack-based buffer overflow vulnerabilities", "trust": 0.6, "url": "http://www.cnnvd.org.cn/web/xxk/bdxqById.tag?id=62185" }, { "title": "The Register", "trust": 0.2, "url": "https://www.theregister.co.uk/2017/12/05/android_december_security_bulletin/" }, { "title": "Debian CVElist Bug Report Logs: CVE-2016-4429", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=debian_cvelist_bugreportlogs\u0026qid=2f5b4ce90152a3bb4f395a0901e7e132" }, { "title": "Ubuntu Security Notice: libtirpc vulnerabilities", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=ubuntu_security_notice\u0026qid=USN-3759-1" }, { "title": "Ubuntu Security Notice: libtirpc vulnerabilities", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=ubuntu_security_notice\u0026qid=USN-3759-2" }, { "title": "Ubuntu Security Notice: eglibc, glibc regression", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=ubuntu_security_notice\u0026qid=USN-3239-2" }, { "title": "Ubuntu Security Notice: eglibc regression", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=ubuntu_security_notice\u0026qid=USN-3239-3" }, { "title": "Ubuntu Security Notice: eglibc, glibc vulnerabilities", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=ubuntu_security_notice\u0026qid=USN-3239-1" }, { "title": "Android Security Bulletins: Android Security Bulletin\u2014December 2017", "trust": 0.1, "url": "https://vulmon.com/vendoradvisory?qidtp=android_security_bulletins\u0026qid=61f816ea19e8d4351da6636b7a63eb7d" } ], "sources": [ { "db": "VULMON", "id": "CVE-2016-4429" }, { "db": "JVNDB", "id": "JVNDB-2016-003093" }, { "db": "CNNVD", "id": "CNNVD-201606-230" } ] }, "problemtype_data": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/problemtype_data#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "problemtype": "CWE-787", "trust": 1.0 }, { "problemtype": "CWE-20", "trust": 0.8 } ], "sources": [ { "db": "JVNDB", "id": "JVNDB-2016-003093" }, { "db": "NVD", "id": "CVE-2016-4429" } ] }, "references": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/references#", "data": { "@container": "@list" }, "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": [ { "trust": 3.0, "url": "http://www.securityfocus.com/bid/102073" }, { "trust": 2.0, "url": "https://sourceware.org/bugzilla/show_bug.cgi?id=20112" }, { "trust": 2.0, "url": "http://www-01.ibm.com/support/docview.wss?uid=swg21995039" }, { "trust": 2.0, "url": "https://source.android.com/security/bulletin/2017-12-01" }, { "trust": 1.8, "url": "https://usn.ubuntu.com/3759-1/" }, { "trust": 1.7, "url": "http://lists.opensuse.org/opensuse-updates/2016-06/msg00030.html" }, { "trust": 1.7, "url": "http://lists.opensuse.org/opensuse-updates/2016-07/msg00039.html" }, { "trust": 1.7, "url": "https://usn.ubuntu.com/3759-2/" }, { "trust": 1.7, "url": "https://lists.debian.org/debian-lts-announce/2020/06/msg00027.html" }, { "trust": 1.0, "url": "https://sourceware.org/git/gitweb.cgi?p=glibc.git%3bh=bc779a1a5b3035133024b21e2f339fe4219fb11c" }, { "trust": 1.0, "url": "https://www.oracle.com//security-alerts/cpujul2021.html" }, { "trust": 0.8, "url": "http://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2016-4429" }, { "trust": 0.8, "url": "http://web.nvd.nist.gov/view/vuln/detail?vulnid=cve-2016-4429" }, { "trust": 0.7, "url": "https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=bc779a1a5b3035133024b21e2f339fe4219fb11c" }, { "trust": 0.6, "url": "https://source.codeaurora.org/quic/la/kernel/msm-3.18/commit/?id=8c4901802968b8c8356860ee689b1ef9cd2cbfe4" }, { "trust": 0.6, "url": "https://source.codeaurora.org/quic/la/kernel/msm-3.18/commit/?id=11e7de77bd5ab0a7706a013598f845ad0c4a8b4c" }, { "trust": 0.6, "url": "https://source.codeaurora.org/quic/la/abl/tianocore/edk2/commit/?id=5c710156bb55b0a085da7c4142b124f3cd986d25" }, { "trust": 0.6, "url": "https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/qcacld-3.0/commit/?id=b15f0ff7351eb6b6a8f6694b4cd5ad27145bd439" }, { "trust": 0.6, "url": "https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/qcacld-2.0/commit/?id=613f91ebcd0838c2c2bec3657e36dd57fcc6a7ea" }, { "trust": 0.6, "url": "https://source.codeaurora.org/quic/la//kernel/msm-4.4/commit/?id=aab2cc06db7cb6c7589bef71e65b5acfa58adc33" }, { "trust": 0.6, "url": "https://source.codeaurora.org/quic/le/oe/recipes/commit/?h=lnx.le.5.3\u0026id=6cfcc1c582a565f5360f7a3977f4a8f42d5245cd" }, { "trust": 0.6, "url": "http://code.google.com/android/" }, { "trust": 0.6, "url": "https://www.oracle.com/security-alerts/cpujul2021.html" }, { "trust": 0.6, "url": "https://www.auscert.org.au/bulletins/esb-2020.2223/" }, { "trust": 0.5, "url": "https://nvd.nist.gov/vuln/detail/cve-2016-4429" }, { "trust": 0.3, "url": "http://www.gnu.org/software/libc/" }, { "trust": 0.3, "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1337136" }, { "trust": 0.3, "url": "https://support.f5.com/kb/en-us/solutions/public/k/17/sol17075474.html" }, { "trust": 0.3, "url": "http://www-01.ibm.com/support/docview.wss?uid=swg21996174" }, { "trust": 0.3, "url": "http://www-01.ibm.com/support/docview.wss?uid=swg21996177" }, { "trust": 0.3, "url": "https://nvd.nist.gov/vuln/detail/cve-2016-1234" }, { "trust": 0.3, "url": "https://nvd.nist.gov/vuln/detail/cve-2016-3706" }, { "trust": 0.3, "url": "http://www.ubuntu.com/usn/usn-3239-1" }, { "trust": 0.3, "url": "https://nvd.nist.gov/vuln/detail/cve-2015-8982" }, { "trust": 0.3, "url": "https://nvd.nist.gov/vuln/detail/cve-2016-5417" }, { "trust": 0.3, "url": "https://nvd.nist.gov/vuln/detail/cve-2016-6323" }, { "trust": 0.3, "url": "https://nvd.nist.gov/vuln/detail/cve-2015-8984" }, { "trust": 0.3, "url": "https://nvd.nist.gov/vuln/detail/cve-2015-8983" }, { "trust": 0.2, "url": "https://usn.ubuntu.com/usn/usn-3759-1" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2017-8779" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2018-14622" }, { "trust": 0.2, "url": "https://nvd.nist.gov/vuln/detail/cve-2015-5180" }, { "trust": 0.1, "url": "https://cwe.mitre.org/data/definitions/787.html" }, { "trust": 0.1, "url": "https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840347" }, { "trust": 0.1, "url": "https://nvd.nist.gov" }, { "trust": 0.1, "url": "https://usn.ubuntu.com/usn/usn-3759-2" }, { "trust": 0.1, "url": "https://bugs.launchpad.net/bugs/1674776" }, { "trust": 0.1, "url": "http://www.ubuntu.com/usn/usn-3239-3" }, { "trust": 0.1, "url": "https://launchpad.net/ubuntu/+source/eglibc/2.15-0ubuntu10.18" }, { "trust": 0.1, "url": "https://launchpad.net/ubuntu/+source/libtirpc/0.2.5-1.2ubuntu0.1" }, { "trust": 0.1, "url": "https://launchpad.net/ubuntu/+source/libtirpc/0.2.5-1ubuntu0.1" }, { "trust": 0.1, "url": "https://launchpad.net/ubuntu/+source/libtirpc/0.2.2-5ubuntu2.1" }, { "trust": 0.1, "url": "https://bugs.launchpad.net/bugs/1674532" }, { "trust": 0.1, "url": "https://launchpad.net/ubuntu/+source/eglibc/2.19-0ubuntu6.11" }, { "trust": 0.1, "url": "https://launchpad.net/ubuntu/+source/eglibc/2.15-0ubuntu10.17" }, { "trust": 0.1, "url": "https://launchpad.net/ubuntu/+source/glibc/2.23-0ubuntu7" }, { "trust": 0.1, "url": "http://www.ubuntu.com/usn/usn-3239-2" }, { "trust": 0.1, "url": "https://launchpad.net/ubuntu/+source/eglibc/2.19-0ubuntu6.10" }, { "trust": 0.1, "url": "https://launchpad.net/ubuntu/+source/glibc/2.23-0ubuntu6" }, { "trust": 0.1, "url": "https://launchpad.net/ubuntu/+source/eglibc/2.15-0ubuntu10.16" } ], "sources": [ { "db": "VULMON", "id": "CVE-2016-4429" }, { "db": "BID", "id": "90737" }, { "db": "JVNDB", "id": "JVNDB-2016-003093" }, { "db": "PACKETSTORM", "id": "149244" }, { "db": "PACKETSTORM", "id": "141812" }, { "db": "PACKETSTORM", "id": "149243" }, { "db": "PACKETSTORM", "id": "141758" }, { "db": "PACKETSTORM", "id": "141749" }, { "db": "CNNVD", "id": "CNNVD-201606-230" }, { "db": "NVD", "id": "CVE-2016-4429" } ] }, "sources": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#", "data": { "@container": "@list" } }, "data": [ { "db": "VULMON", "id": "CVE-2016-4429" }, { "db": "BID", "id": "90737" }, { "db": "JVNDB", "id": "JVNDB-2016-003093" }, { "db": "PACKETSTORM", "id": "149244" }, { "db": "PACKETSTORM", "id": "141812" }, { "db": "PACKETSTORM", "id": "149243" }, { "db": "PACKETSTORM", "id": "141758" }, { "db": "PACKETSTORM", "id": "141749" }, { "db": "CNNVD", "id": "CNNVD-201606-230" }, { "db": "NVD", "id": "CVE-2016-4429" } ] }, "sources_release_date": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources_release_date#", "data": { "@container": "@list" } }, "data": [ { "date": "2016-06-10T00:00:00", "db": "VULMON", "id": "CVE-2016-4429" }, { "date": "2016-05-18T00:00:00", "db": "BID", "id": "90737" }, { "date": "2016-06-14T00:00:00", "db": "JVNDB", "id": "JVNDB-2016-003093" }, { "date": "2018-09-05T22:46:01", "db": "PACKETSTORM", "id": "149244" }, { "date": "2017-03-24T15:02:31", "db": "PACKETSTORM", "id": "141812" }, { "date": "2018-09-05T22:45:49", "db": "PACKETSTORM", "id": "149243" }, { "date": "2017-03-22T14:12:01", "db": "PACKETSTORM", "id": "141758" }, { "date": "2017-03-21T14:50:15", "db": "PACKETSTORM", "id": "141749" }, { "date": "2016-06-12T00:00:00", "db": "CNNVD", "id": "CNNVD-201606-230" }, { "date": "2016-06-10T15:59:05.687000", "db": "NVD", "id": "CVE-2016-4429" } ] }, "sources_update_date": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources_update_date#", "data": { "@container": "@list" } }, "data": [ { "date": "2021-07-20T00:00:00", "db": "VULMON", "id": "CVE-2016-4429" }, { "date": "2016-05-18T00:00:00", "db": "BID", "id": "90737" }, { "date": "2016-06-14T00:00:00", "db": "JVNDB", "id": "JVNDB-2016-003093" }, { "date": "2021-07-21T00:00:00", "db": "CNNVD", "id": "CNNVD-201606-230" }, { "date": "2023-11-07T02:32:37.350000", "db": "NVD", "id": "CVE-2016-4429" } ] }, "threat_type": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/threat_type#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "remote", "sources": [ { "db": "CNNVD", "id": "CNNVD-201606-230" } ], "trust": 0.6 }, "title": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/title#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "GNU C Library of sunrpc/clnt_udp.c of clntudp_call Function vulnerable to stack-based buffer overflow", "sources": [ { "db": "JVNDB", "id": "JVNDB-2016-003093" } ], "trust": 0.8 }, "type": { "@context": { "@vocab": "https://www.variotdbs.pl/ref/type#", "sources": { "@container": "@list", "@context": { "@vocab": "https://www.variotdbs.pl/ref/sources#" } } }, "data": "buffer error", "sources": [ { "db": "CNNVD", "id": "CNNVD-201606-230" } ], "trust": 0.6 } }
cve-2023-0687
Vulnerability from cvelistv5
{ "containers": { "adp": [ { "providerMetadata": { "dateUpdated": "2024-08-02T05:17:50.332Z", "orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE" }, "references": [ { "tags": [ "x_transferred" ], "url": "https://vuldb.com/?id.220246" }, { "tags": [ "x_transferred" ], "url": "https://vuldb.com/?ctiid.220246" }, { "tags": [ "x_transferred" ], "url": "https://sourceware.org/bugzilla/show_bug.cgi?id=29444" }, { "tags": [ "x_transferred" ], "url": "https://patchwork.sourceware.org/project/glibc/patch/20230204114138.5436-1-leo%40yuriev.ru/" } ], "title": "CVE Program Container" }, { "metrics": [ { "other": { "content": { "id": "CVE-2023-0687", "options": [ { "Exploitation": "none" }, { "Automatable": "no" }, { "Technical Impact": "partial" } ], "role": "CISA Coordinator", "timestamp": "2024-11-25T15:41:00.523281Z", "version": "2.0.3" }, "type": "ssvc" } } ], "providerMetadata": { "dateUpdated": "2024-11-25T15:41:37.840Z", "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP" }, "title": "CISA ADP Vulnrichment" } ], "cna": { "affected": [ { "product": "C Library", "vendor": "GNU", "versions": [ { "status": "affected", "version": "2.38" } ] } ], "descriptions": [ { "lang": "en", "value": "A vulnerability was found in GNU C Library 2.38. It has been declared as critical. This vulnerability affects the function __monstartup of the file gmon.c of the component Call Graph Monitor. The manipulation leads to buffer overflow. It is recommended to apply a patch to fix this issue. VDB-220246 is the identifier assigned to this vulnerability. NOTE: The real existence of this vulnerability is still doubted at the moment. The inputs that induce this vulnerability are basically addresses of the running application that is built with gmon enabled. It\u0027s basically trusted input or input that needs an actual security flaw to be compromised or controlled." }, { "lang": "de", "value": "In GNU C Library 2.38 wurde eine Schwachstelle ausgemacht. Sie wurde als kritisch eingestuft. Das betrifft die Funktion __monstartup der Datei gmon.c der Komponente Call Graph Monitor. Durch Manipulation mit unbekannten Daten kann eine buffer overflow-Schwachstelle ausgenutzt werden. Als bestm\u00f6gliche Massnahme wird Patching empfohlen." } ], "metrics": [ { "cvssV3_0": { "attackComplexity": "HIGH", "attackVector": "ADJACENT_NETWORK", "availabilityImpact": "LOW", "baseScore": 4.6, "baseSeverity": "MEDIUM", "confidentialityImpact": "LOW", "integrityImpact": "LOW", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.0/AV:A/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L", "version": "3.0" }, "cvssV3_1": { "attackComplexity": "HIGH", "attackVector": "ADJACENT_NETWORK", "availabilityImpact": "LOW", "baseScore": 4.6, "baseSeverity": "MEDIUM", "confidentialityImpact": "LOW", "integrityImpact": "LOW", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L", "version": "3.1" } } ], "problemTypes": [ { "descriptions": [ { "cweId": "CWE-120", "description": "CWE-120 Buffer Overflow", "lang": "en", "type": "CWE" } ] } ], "providerMetadata": { "dateUpdated": "2023-02-24T00:00:00", "orgId": "1af790b2-7ee1-4545-860a-a788eba489b5", "shortName": "VulDB" }, "references": [ { "url": "https://vuldb.com/?id.220246" }, { "url": "https://vuldb.com/?ctiid.220246" }, { "url": "https://sourceware.org/bugzilla/show_bug.cgi?id=29444" }, { "url": "https://patchwork.sourceware.org/project/glibc/patch/20230204114138.5436-1-leo%40yuriev.ru/" } ], "tags": [ "disputed" ] } }, "cveMetadata": { "assignerOrgId": "1af790b2-7ee1-4545-860a-a788eba489b5", "assignerShortName": "VulDB", "cveId": "CVE-2023-0687", "datePublished": "2023-02-06T00:00:00", "dateReserved": "2023-02-06T00:00:00", "dateUpdated": "2024-11-25T15:41:37.840Z", "state": "PUBLISHED" }, "dataType": "CVE_RECORD", "dataVersion": "5.1" }