diff --git a/changelog/security/2023-08-01-openssl-shadow.md b/changelog/security/2023-08-01-openssl-shadow.md new file mode 100644 index 00000000000..f38f789a376 --- /dev/null +++ b/changelog/security/2023-08-01-openssl-shadow.md @@ -0,0 +1,2 @@ +- OpenSSL ([CVE-2023-2975](https://nvd.nist.gov/vuln/detail/CVE-2023-2975), [CVE-2023-3446](https://nvd.nist.gov/vuln/detail/CVE-2023-3446)) +- shadow ([CVE-2023-29383](https://nvd.nist.gov/vuln/detail/CVE-2023-29383)) diff --git a/sdk_container/src/third_party/coreos-overlay/dev-libs/openssl/files/gentoo.config-1.0.4 b/sdk_container/src/third_party/coreos-overlay/dev-libs/openssl/files/gentoo.config-1.0.4 index 573a97de354..ef1c6f1768a 100644 --- a/sdk_container/src/third_party/coreos-overlay/dev-libs/openssl/files/gentoo.config-1.0.4 +++ b/sdk_container/src/third_party/coreos-overlay/dev-libs/openssl/files/gentoo.config-1.0.4 @@ -1,5 +1,5 @@ #!/usr/bin/env bash -# Copyright 1999-2020 Gentoo Authors +# Copyright 1999-2023 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 # # Openssl doesn't play along nicely with cross-compiling @@ -77,7 +77,9 @@ fi # Detect target arch machine="" +submachine="" chost_machine=${CHOST%%-*} +[[ ${CC} == *clang* ]] && submachine="-clang" case ${system} in linux) case ${chost_machine}:${ABI} in @@ -95,7 +97,7 @@ linux) # hppa64*) machine=parisc64;; hppa*) machine="generic32 -DB_ENDIAN";; i[0-9]86*|\ - x86_64*:x86) machine=x86;; + x86_64*:x86) machine=x86${submachine};; ia64*) machine=ia64;; loongarch64*) machine="loongarch64 -DL_ENDIAN" system=linux64;; m68*) machine="latomic -DB_ENDIAN";; @@ -109,7 +111,9 @@ linux) powerpc64*) machine=ppc64;; powerpc*le*) machine="generic32 -DL_ENDIAN";; powerpc*) machine=ppc;; + riscv32be*) machine="generic32 -DB_ENDIAN";; riscv32*) machine="generic32 -DL_ENDIAN";; + riscv64be*) machine="riscv64 -DB_ENDIAN" system=linux64;; riscv64*) machine="riscv64 -DL_ENDIAN" system=linux64;; # sh64*) machine=elf;; sh*b*) machine="generic32 -DB_ENDIAN";; @@ -125,7 +129,7 @@ linux) s390x*) machine=s390x system=linux64;; s390*) machine="generic32 -DB_ENDIAN";; x86_64*:x32) machine=x32;; - x86_64*) machine=x86_64;; + x86_64*) machine=x86_64${submachine};; esac ;; BSD) diff --git a/sdk_container/src/third_party/coreos-overlay/dev-libs/openssl/files/openssl-3.0.9-CVE-2023-2975.patch b/sdk_container/src/third_party/coreos-overlay/dev-libs/openssl/files/openssl-3.0.9-CVE-2023-2975.patch new file mode 100644 index 00000000000..908e57251cb --- /dev/null +++ b/sdk_container/src/third_party/coreos-overlay/dev-libs/openssl/files/openssl-3.0.9-CVE-2023-2975.patch @@ -0,0 +1,109 @@ +https://github.com/openssl/openssl/commit/00e2f5eea29994d19293ec4e8c8775ba73678598 +https://github.com/openssl/openssl/commit/96318a8d21bed334d78797eca5b32790775d5f05 + +From 00e2f5eea29994d19293ec4e8c8775ba73678598 Mon Sep 17 00:00:00 2001 +From: Tomas Mraz +Date: Tue, 4 Jul 2023 17:30:35 +0200 +Subject: [PATCH] Do not ignore empty associated data with AES-SIV mode + +The AES-SIV mode allows for multiple associated data items +authenticated separately with any of these being 0 length. + +The provided implementation ignores such empty associated data +which is incorrect in regards to the RFC 5297 and is also +a security issue because such empty associated data then become +unauthenticated if an application expects to authenticate them. + +Fixes CVE-2023-2975 + +Reviewed-by: Matt Caswell +Reviewed-by: Paul Dale +(Merged from https://github.com/openssl/openssl/pull/21384) + +(cherry picked from commit c426c281cfc23ab182f7d7d7a35229e7db1494d9) +--- a/providers/implementations/ciphers/cipher_aes_siv.c ++++ b/providers/implementations/ciphers/cipher_aes_siv.c +@@ -120,14 +120,18 @@ static int siv_cipher(void *vctx, unsigned char *out, size_t *outl, + if (!ossl_prov_is_running()) + return 0; + +- if (inl == 0) { +- *outl = 0; +- return 1; +- } ++ /* Ignore just empty encryption/decryption call and not AAD. */ ++ if (out != NULL) { ++ if (inl == 0) { ++ if (outl != NULL) ++ *outl = 0; ++ return 1; ++ } + +- if (outsize < inl) { +- ERR_raise(ERR_LIB_PROV, PROV_R_OUTPUT_BUFFER_TOO_SMALL); +- return 0; ++ if (outsize < inl) { ++ ERR_raise(ERR_LIB_PROV, PROV_R_OUTPUT_BUFFER_TOO_SMALL); ++ return 0; ++ } + } + + if (ctx->hw->cipher(ctx, out, in, inl) <= 0) + +From 96318a8d21bed334d78797eca5b32790775d5f05 Mon Sep 17 00:00:00 2001 +From: Tomas Mraz +Date: Tue, 4 Jul 2023 17:50:37 +0200 +Subject: [PATCH] Add testcases for empty associated data entries with AES-SIV + +Reviewed-by: Matt Caswell +Reviewed-by: Paul Dale +(Merged from https://github.com/openssl/openssl/pull/21384) + +(cherry picked from commit 3993bb0c0c87e3ed0ab4274e4688aa814e164cfc) +--- a/test/recipes/30-test_evp_data/evpciph_aes_siv.txt ++++ b/test/recipes/30-test_evp_data/evpciph_aes_siv.txt +@@ -20,6 +20,19 @@ Tag = 85632d07c6e8f37f950acd320a2ecc93 + Plaintext = 112233445566778899aabbccddee + Ciphertext = 40c02b9690c4dc04daef7f6afe5c + ++Cipher = aes-128-siv ++Key = fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff ++Tag = f1c5fdeac1f15a26779c1501f9fb7588 ++Plaintext = 112233445566778899aabbccddee ++Ciphertext = 27e946c669088ab06da58c5c831c ++ ++Cipher = aes-128-siv ++Key = fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff ++AAD = ++Tag = d1022f5b3664e5a4dfaf90f85be6f28a ++Plaintext = 112233445566778899aabbccddee ++Ciphertext = b66cff6b8eca0b79f083b39a0901 ++ + Cipher = aes-128-siv + Key = 7f7e7d7c7b7a79787776757473727170404142434445464748494a4b4c4d4e4f + AAD = 00112233445566778899aabbccddeeffdeaddadadeaddadaffeeddccbbaa99887766554433221100 +@@ -29,6 +42,24 @@ Tag = 7bdb6e3b432667eb06f4d14bff2fbd0f + Plaintext = 7468697320697320736f6d6520706c61696e7465787420746f20656e6372797074207573696e67205349562d414553 + Ciphertext = cb900f2fddbe404326601965c889bf17dba77ceb094fa663b7a3f748ba8af829ea64ad544a272e9c485b62a3fd5c0d + ++Cipher = aes-128-siv ++Key = 7f7e7d7c7b7a79787776757473727170404142434445464748494a4b4c4d4e4f ++AAD = 00112233445566778899aabbccddeeffdeaddadadeaddadaffeeddccbbaa99887766554433221100 ++AAD = ++AAD = 09f911029d74e35bd84156c5635688c0 ++Tag = 83ce6593a8fa67eb6fcd2819cedfc011 ++Plaintext = 7468697320697320736f6d6520706c61696e7465787420746f20656e6372797074207573696e67205349562d414553 ++Ciphertext = 30d937b42f71f71f93fc2d8d702d3eac8dc7651eefcd81120081ff29d626f97f3de17f2969b691c91b69b652bf3a6d ++ ++Cipher = aes-128-siv ++Key = 7f7e7d7c7b7a79787776757473727170404142434445464748494a4b4c4d4e4f ++AAD = ++AAD = 00112233445566778899aabbccddeeffdeaddadadeaddadaffeeddccbbaa99887766554433221100 ++AAD = 09f911029d74e35bd84156c5635688c0 ++Tag = 77dd4a44f5a6b41302121ee7f378de25 ++Plaintext = 7468697320697320736f6d6520706c61696e7465787420746f20656e6372797074207573696e67205349562d414553 ++Ciphertext = 0fcd664c922464c88939d71fad7aefb864e501b0848a07d39201c1067a7288f3dadf0131a823a0bc3d588e8564a5fe ++ + Cipher = aes-192-siv + Key = fffefdfcfbfaf9f8f7f6f5f4f3f2f1f0f0f1f2f3f4f5f6f7f8f9fafbfcfdfefffffefdfcfbfaf9f8f7f6f5f4f3f2f1f0 + AAD = 101112131415161718191a1b1c1d1e1f2021222324252627 diff --git a/sdk_container/src/third_party/coreos-overlay/dev-libs/openssl/files/openssl-3.0.9-CVE-2023-3446.patch b/sdk_container/src/third_party/coreos-overlay/dev-libs/openssl/files/openssl-3.0.9-CVE-2023-3446.patch new file mode 100644 index 00000000000..1a1be6a8af5 --- /dev/null +++ b/sdk_container/src/third_party/coreos-overlay/dev-libs/openssl/files/openssl-3.0.9-CVE-2023-3446.patch @@ -0,0 +1,120 @@ +https://github.com/openssl/openssl/commit/1fa20cf2f506113c761777127a38bce5068740eb +https://github.com/openssl/openssl/commit/8a62fd996cb1c22383ec75b4155d54dec4a1b0ee + +From 1fa20cf2f506113c761777127a38bce5068740eb Mon Sep 17 00:00:00 2001 +From: Matt Caswell +Date: Thu, 6 Jul 2023 16:36:35 +0100 +Subject: [PATCH] Fix DH_check() excessive time with over sized modulus + +The DH_check() function checks numerous aspects of the key or parameters +that have been supplied. Some of those checks use the supplied modulus +value even if it is excessively large. + +There is already a maximum DH modulus size (10,000 bits) over which +OpenSSL will not generate or derive keys. DH_check() will however still +perform various tests for validity on such a large modulus. We introduce a +new maximum (32,768) over which DH_check() will just fail. + +An application that calls DH_check() and supplies a key or parameters +obtained from an untrusted source could be vulnerable to a Denial of +Service attack. + +The function DH_check() is itself called by a number of other OpenSSL +functions. An application calling any of those other functions may +similarly be affected. The other functions affected by this are +DH_check_ex() and EVP_PKEY_param_check(). + +CVE-2023-3446 + +Reviewed-by: Paul Dale +Reviewed-by: Tom Cosgrove +Reviewed-by: Bernd Edlinger +Reviewed-by: Tomas Mraz +(Merged from https://github.com/openssl/openssl/pull/21451) + +(cherry picked from commit 9e0094e2aa1b3428a12d5095132f133c078d3c3d) +--- a/crypto/dh/dh_check.c ++++ b/crypto/dh/dh_check.c +@@ -152,6 +152,12 @@ int DH_check(const DH *dh, int *ret) + if (nid != NID_undef) + return 1; + ++ /* Don't do any checks at all with an excessively large modulus */ ++ if (BN_num_bits(dh->params.p) > OPENSSL_DH_CHECK_MAX_MODULUS_BITS) { ++ ERR_raise(ERR_LIB_DH, DH_R_MODULUS_TOO_LARGE); ++ return 0; ++ } ++ + if (!DH_check_params(dh, ret)) + return 0; + +--- a/include/openssl/dh.h ++++ b/include/openssl/dh.h +@@ -89,7 +89,11 @@ int EVP_PKEY_CTX_get0_dh_kdf_ukm(EVP_PKEY_CTX *ctx, unsigned char **ukm); + # include + + # ifndef OPENSSL_DH_MAX_MODULUS_BITS +-# define OPENSSL_DH_MAX_MODULUS_BITS 10000 ++# define OPENSSL_DH_MAX_MODULUS_BITS 10000 ++# endif ++ ++# ifndef OPENSSL_DH_CHECK_MAX_MODULUS_BITS ++# define OPENSSL_DH_CHECK_MAX_MODULUS_BITS 32768 + # endif + + # define OPENSSL_DH_FIPS_MIN_MODULUS_BITS 1024 + +From 8a62fd996cb1c22383ec75b4155d54dec4a1b0ee Mon Sep 17 00:00:00 2001 +From: Matt Caswell +Date: Fri, 7 Jul 2023 14:39:48 +0100 +Subject: [PATCH] Add a test for CVE-2023-3446 + +Confirm that the only errors DH_check() finds with DH parameters with an +excessively long modulus is that the modulus is too large. We should not +be performing time consuming checks using that modulus. + +Reviewed-by: Paul Dale +Reviewed-by: Tom Cosgrove +Reviewed-by: Bernd Edlinger +Reviewed-by: Tomas Mraz +(Merged from https://github.com/openssl/openssl/pull/21451) + +(cherry picked from commit ede782b4c8868d1f09c9cd237f82b6f35b7dba8b) +--- a/test/dhtest.c ++++ b/test/dhtest.c +@@ -73,7 +73,7 @@ static int dh_test(void) + goto err1; + + /* check fails, because p is way too small */ +- if (!DH_check(dh, &i)) ++ if (!TEST_true(DH_check(dh, &i))) + goto err2; + i ^= DH_MODULUS_TOO_SMALL; + if (!TEST_false(i & DH_CHECK_P_NOT_PRIME) +@@ -124,6 +124,17 @@ static int dh_test(void) + /* We'll have a stale error on the queue from the above test so clear it */ + ERR_clear_error(); + ++ /* Modulus of size: dh check max modulus bits + 1 */ ++ if (!TEST_true(BN_set_word(p, 1)) ++ || !TEST_true(BN_lshift(p, p, OPENSSL_DH_CHECK_MAX_MODULUS_BITS))) ++ goto err3; ++ ++ /* ++ * We expect no checks at all for an excessively large modulus ++ */ ++ if (!TEST_false(DH_check(dh, &i))) ++ goto err3; ++ + /* + * II) key generation + */ +@@ -138,7 +149,7 @@ static int dh_test(void) + goto err3; + + /* ... and check whether it is valid */ +- if (!DH_check(a, &i)) ++ if (!TEST_true(DH_check(a, &i))) + goto err3; + if (!TEST_false(i & DH_CHECK_P_NOT_PRIME) + || !TEST_false(i & DH_CHECK_P_NOT_SAFE_PRIME) diff --git a/sdk_container/src/third_party/coreos-overlay/dev-libs/openssl/openssl-3.0.9.ebuild b/sdk_container/src/third_party/coreos-overlay/dev-libs/openssl/openssl-3.0.9-r2.ebuild similarity index 92% rename from sdk_container/src/third_party/coreos-overlay/dev-libs/openssl/openssl-3.0.9.ebuild rename to sdk_container/src/third_party/coreos-overlay/dev-libs/openssl/openssl-3.0.9-r2.ebuild index e5032f0e9ca..ad42c2736e0 100644 --- a/sdk_container/src/third_party/coreos-overlay/dev-libs/openssl/openssl-3.0.9.ebuild +++ b/sdk_container/src/third_party/coreos-overlay/dev-libs/openssl/openssl-3.0.9-r2.ebuild @@ -5,7 +5,8 @@ EAPI=8 VERIFY_SIG_OPENPGP_KEY_PATH="${BROOT}"/usr/share/openpgp-keys/openssl.org.asc TMPFILES_OPTIONAL=1 -inherit edo flag-o-matic linux-info toolchain-funcs multilib-minimal multiprocessing verify-sig systemd tmpfiles +inherit edo flag-o-matic linux-info toolchain-funcs +inherit multilib multilib-minimal multiprocessing preserve-libs verify-sig tmpfiles DESCRIPTION="Robust, full-featured Open Source Toolkit for the Transport Layer Security (TLS)" HOMEPAGE="https://www.openssl.org/" @@ -19,7 +20,7 @@ if [[ ${PV} == 9999 ]] ; then else SRC_URI="mirror://openssl/source/${MY_P}.tar.gz verify-sig? ( mirror://openssl/source/${MY_P}.tar.gz.asc )" - KEYWORDS="~alpha amd64 ~arm arm64 ~hppa ~ia64 ~loong ~m68k ~mips ~ppc ~ppc64 ~riscv ~s390 ~sparc ~x86 ~arm64-macos" + KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~loong ~m68k ~mips ~ppc ppc64 ~riscv ~s390 sparc x86 ~arm64-macos" fi S="${WORKDIR}"/${MY_P} @@ -54,6 +55,11 @@ MULTILIB_WRAPPED_HEADERS=( /usr/include/openssl/configuration.h ) +PATCHES=( + "${FILESDIR}"/${P}-CVE-2023-2975.patch + "${FILESDIR}"/${P}-CVE-2023-3446.patch +) + pkg_setup() { if use ktls ; then if kernel_is -lt 4 18 ; then @@ -139,6 +145,11 @@ src_configure() { append-flags $(test-flags-CC -Wa,--noexecstack) + # bug #895308 + append-atomic-flags + # Configure doesn't respect LIBS + export LDLIBS="${LIBS}" + # bug #197996 unset APPS # bug #312551 @@ -216,7 +227,7 @@ multilib_src_compile() { multilib_src_test() { # VFP = show subtests verbosely and show failed tests verbosely # Normal V=1 would show everything verbosely but this slows things down. - emake HARNESS_JOBS="$(makeopts_jobs)" VFP=1 test + emake HARNESS_JOBS="$(makeopts_jobs)" -Onone VFP=1 test } multilib_src_install() { @@ -275,5 +286,7 @@ pkg_preinst() { -module "${ED}/usr/$(get_libdir)/ossl-modules/fips.so" eend $? fi -} + preserve_old_lib /usr/$(get_libdir)/lib{crypto,ssl}$(get_libname 1) \ + /usr/$(get_libdir)/lib{crypto,ssl}$(get_libname 1.1) +} diff --git a/sdk_container/src/third_party/coreos-overlay/sys-apps/shadow/files/shadow-4.1.3-dots-in-usernames.patch b/sdk_container/src/third_party/coreos-overlay/sys-apps/shadow/files/shadow-4.1.3-dots-in-usernames.patch deleted file mode 100644 index efcb33dbd9e..00000000000 --- a/sdk_container/src/third_party/coreos-overlay/sys-apps/shadow/files/shadow-4.1.3-dots-in-usernames.patch +++ /dev/null @@ -1,10 +0,0 @@ ---- shadow-4.1.3/libmisc/chkname.c -+++ shadow-4.1.3/libmisc/chkname.c -@@ -66,6 +66,7 @@ - ( ('0' <= *name) && ('9' >= *name) ) || - ('_' == *name) || - ('-' == *name) || -+ ('.' == *name) || - ( ('$' == *name) && ('\0' == *(name + 1)) ) - )) { - return false; diff --git a/sdk_container/src/third_party/coreos-overlay/sys-apps/shadow/files/shadow-4.13-CVE-2023-29383.patch b/sdk_container/src/third_party/coreos-overlay/sys-apps/shadow/files/shadow-4.13-CVE-2023-29383.patch new file mode 100644 index 00000000000..49868ba67c9 --- /dev/null +++ b/sdk_container/src/third_party/coreos-overlay/sys-apps/shadow/files/shadow-4.13-CVE-2023-29383.patch @@ -0,0 +1,100 @@ +From e5905c4b84d4fb90aefcd96ee618411ebfac663d Mon Sep 17 00:00:00 2001 +From: tomspiderlabs <128755403+tomspiderlabs@users.noreply.github.com> +Date: Thu, 23 Mar 2023 23:39:38 +0000 +Subject: [PATCH] Added control character check + +Added control character check, returning -1 (to "err") if control characters are present. +--- + lib/fields.c | 11 +++++++---- + 1 file changed, 7 insertions(+), 4 deletions(-) + +diff --git a/lib/fields.c b/lib/fields.c +index 640be931f..fb51b5829 100644 +--- a/lib/fields.c ++++ b/lib/fields.c +@@ -21,9 +21,9 @@ + * + * The supplied field is scanned for non-printable and other illegal + * characters. +- * + -1 is returned if an illegal character is present. +- * + 1 is returned if no illegal characters are present, but the field +- * contains a non-printable character. ++ * + -1 is returned if an illegal or control character is present. ++ * + 1 is returned if no illegal or control characters are present, ++ * but the field contains a non-printable character. + * + 0 is returned otherwise. + */ + int valid_field (const char *field, const char *illegal) +@@ -45,10 +45,13 @@ int valid_field (const char *field, const char *illegal) + } + + if (0 == err) { +- /* Search if there are some non-printable characters */ ++ /* Search if there are non-printable or control characters */ + for (cp = field; '\0' != *cp; cp++) { + if (!isprint (*cp)) { + err = 1; ++ } ++ if (!iscntrl (*cp)) { ++ err = -1; + break; + } + } +From 2eaea70111f65b16d55998386e4ceb4273c19eb4 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Christian=20G=C3=B6ttsche?= +Date: Fri, 31 Mar 2023 14:46:50 +0200 +Subject: [PATCH] Overhaul valid_field() + +e5905c4b ("Added control character check") introduced checking for +control characters but had the logic inverted, so it rejects all +characters that are not control ones. + +Cast the character to `unsigned char` before passing to the character +checking functions to avoid UB. + +Use strpbrk(3) for the illegal character test and return early. +--- + lib/fields.c | 24 ++++++++++-------------- + 1 file changed, 10 insertions(+), 14 deletions(-) + +diff --git a/lib/fields.c b/lib/fields.c +index fb51b5829..539292485 100644 +--- a/lib/fields.c ++++ b/lib/fields.c +@@ -37,26 +37,22 @@ int valid_field (const char *field, const char *illegal) + + /* For each character of field, search if it appears in the list + * of illegal characters. */ ++ if (illegal && NULL != strpbrk (field, illegal)) { ++ return -1; ++ } ++ ++ /* Search if there are non-printable or control characters */ + for (cp = field; '\0' != *cp; cp++) { +- if (strchr (illegal, *cp) != NULL) { ++ unsigned char c = *cp; ++ if (!isprint (c)) { ++ err = 1; ++ } ++ if (iscntrl (c)) { + err = -1; + break; + } + } + +- if (0 == err) { +- /* Search if there are non-printable or control characters */ +- for (cp = field; '\0' != *cp; cp++) { +- if (!isprint (*cp)) { +- err = 1; +- } +- if (!iscntrl (*cp)) { +- err = -1; +- break; +- } +- } +- } +- + return err; + } + diff --git a/sdk_container/src/third_party/coreos-overlay/sys-apps/shadow/files/shadow-4.13-password-leak.patch b/sdk_container/src/third_party/coreos-overlay/sys-apps/shadow/files/shadow-4.13-password-leak.patch new file mode 100644 index 00000000000..25b5ec39c5f --- /dev/null +++ b/sdk_container/src/third_party/coreos-overlay/sys-apps/shadow/files/shadow-4.13-password-leak.patch @@ -0,0 +1,135 @@ +https://github.com/shadow-maint/shadow/commit/65c88a43a23c2391dcc90c0abda3e839e9c57904 + +From 65c88a43a23c2391dcc90c0abda3e839e9c57904 Mon Sep 17 00:00:00 2001 +From: Alejandro Colomar +Date: Sat, 10 Jun 2023 16:20:05 +0200 +Subject: [PATCH] gpasswd(1): Fix password leak + +How to trigger this password leak? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +When gpasswd(1) asks for the new password, it asks twice (as is usual +for confirming the new password). Each of those 2 password prompts +uses agetpass() to get the password. If the second agetpass() fails, +the first password, which has been copied into the 'static' buffer +'pass' via STRFCPY(), wasn't being zeroed. + +agetpass() is defined in <./libmisc/agetpass.c> (around line 91), and +can fail for any of the following reasons: + +- malloc(3) or readpassphrase(3) failure. + + These are going to be difficult to trigger. Maybe getting the system + to the limits of memory utilization at that exact point, so that the + next malloc(3) gets ENOMEM, and possibly even the OOM is triggered. + About readpassphrase(3), ENFILE and EINTR seem the only plausible + ones, and EINTR probably requires privilege or being the same user; + but I wouldn't discard ENFILE so easily, if a process starts opening + files. + +- The password is longer than PASS_MAX. + + The is plausible with physical access. However, at that point, a + keylogger will be a much simpler attack. + +And, the attacker must be able to know when the second password is being +introduced, which is not going to be easy. + +How to read the password after the leak? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Provoking the leak yourself at the right point by entering a very long +password is easy, and inspecting the process stack at that point should +be doable. Try to find some consistent patterns. + +Then, search for those patterns in free memory, right after the victim +leaks their password. + +Once you get the leak, a program should read all the free memory +searching for patterns that gpasswd(1) leaves nearby the leaked +password. + +On 6/10/23 03:14, Seth Arnold wrote: +> An attacker process wouldn't be able to use malloc(3) for this task. +> There's a handful of tools available for userspace to allocate memory: +> +> - brk / sbrk +> - mmap MAP_ANONYMOUS +> - mmap /dev/zero +> - mmap some other file +> - shm_open +> - shmget +> +> Most of these return only pages of zeros to a process. Using mmap of an +> existing file, you can get some of the contents of the file demand-loaded +> into the memory space on the first use. +> +> The MAP_UNINITIALIZED flag only works if the kernel was compiled with +> CONFIG_MMAP_ALLOW_UNINITIALIZED. This is rare. +> +> malloc(3) doesn't zero memory, to our collective frustration, but all the +> garbage in the allocations is from previous allocations in the current +> process. It isn't leftover from other processes. +> +> The avenues available for reading the memory: +> - /dev/mem and /dev/kmem (requires root, not available with Secure Boot) +> - /proc/pid/mem (requires ptrace privileges, mediated by YAMA) +> - ptrace (requires ptrace privileges, mediated by YAMA) +> - causing memory to be swapped to disk, and then inspecting the swap +> +> These all require a certain amount of privileges. + +How to fix it? +~~~~~~~~~~~~~ + +memzero(), which internally calls explicit_bzero(3), or whatever +alternative the system provides with a slightly different name, will +make sure that the buffer is zeroed in memory, and optimizations are not +allowed to impede this zeroing. + +This is not really 100% effective, since compilers may place copies of +the string somewhere hidden in the stack. Those copies won't get zeroed +by explicit_bzero(3). However, that's arguably a compiler bug, since +compilers should make everything possible to avoid optimizing strings +that are later passed to explicit_bzero(3). But we all know that +sometimes it's impossible to have perfect knowledge in the compiler, so +this is plausible. Nevertheless, there's nothing we can do against such +issues, except minimizing the time such passwords are stored in plain +text. + +Security concerns +~~~~~~~~~~~~~~~~ + +We believe this isn't easy to exploit. Nevertheless, and since the fix +is trivial, this fix should probably be applied soon, and backported to +all supported distributions, to prevent someone else having more +imagination than us to find a way. + +Affected versions +~~~~~~~~~~~~~~~~ + +All. Bug introduced in shadow 19990709. That's the second commit in +the git history. + +Fixes: 45c6603cc86c ("[svn-upgrade] Integrating new upstream version, shadow (19990709)") +Reported-by: Alejandro Colomar +Cc: Serge Hallyn +Cc: Iker Pedrosa +Cc: Seth Arnold +Cc: Christian Brauner +Cc: Balint Reczey +Cc: Sam James +Cc: David Runge +Cc: Andreas Jaeger +Cc: <~hallyn/shadow@lists.sr.ht> +Signed-off-by: Alejandro Colomar +--- a/src/gpasswd.c ++++ b/src/gpasswd.c +@@ -898,6 +898,7 @@ static void change_passwd (struct group *gr) + erase_pass (cp); + cp = agetpass (_("Re-enter new password: ")); + if (NULL == cp) { ++ memzero (pass, sizeof pass); + exit (1); + } + diff --git a/sdk_container/src/third_party/coreos-overlay/sys-apps/shadow/files/shadow-4.13-usermod-prefix-gid.patch b/sdk_container/src/third_party/coreos-overlay/sys-apps/shadow/files/shadow-4.13-usermod-prefix-gid.patch new file mode 100644 index 00000000000..50cbe699d15 --- /dev/null +++ b/sdk_container/src/third_party/coreos-overlay/sys-apps/shadow/files/shadow-4.13-usermod-prefix-gid.patch @@ -0,0 +1,33 @@ +https://bugs.gentoo.org/903083 +https://github.com/shadow-maint/shadow/pull/691 +https://github.com/shadow-maint/shadow/commit/bd2d0079c90241f24671a7946a3ad175dc1a3aeb + +From fcb04de38a0ddc263288a1c450b35bfb1503d523 Mon Sep 17 00:00:00 2001 +From: Mike Gilbert +Date: Sat, 25 Mar 2023 21:16:55 -0400 +Subject: [PATCH] usermod: respect --prefix for --gid option + +The --gid option accepts a group name or id. When a name is provided, it +is resolved to an id by looking up the name in the group database +(/etc/group). + +The --prefix option overides the location of the passwd and group +databases. I suspect the --gid option was overlooked when wiring up the +--prefix option. + +useradd --gid already respects --prefix; this change makes usermod +behave the same way. + +Fixes: b6b2c756c91806b1c3e150ea0ee4721c6cdaf9d0 +Signed-off-by: Mike Gilbert +--- a/src/usermod.c ++++ b/src/usermod.c +@@ -1072,7 +1072,7 @@ static void process_flags (int argc, char **argv) + fflg = true; + break; + case 'g': +- grp = getgr_nam_gid (optarg); ++ grp = prefix_getgr_nam_gid (optarg); + if (NULL == grp) { + fprintf (stderr, + _("%s: group '%s' does not exist\n"), diff --git a/sdk_container/src/third_party/coreos-overlay/sys-apps/shadow/shadow-4.13-r1.ebuild b/sdk_container/src/third_party/coreos-overlay/sys-apps/shadow/shadow-4.13-r4.ebuild similarity index 92% rename from sdk_container/src/third_party/coreos-overlay/sys-apps/shadow/shadow-4.13-r1.ebuild rename to sdk_container/src/third_party/coreos-overlay/sys-apps/shadow/shadow-4.13-r4.ebuild index 682625ab584..51cecb5afd7 100644 --- a/sdk_container/src/third_party/coreos-overlay/sys-apps/shadow/shadow-4.13-r1.ebuild +++ b/sdk_container/src/third_party/coreos-overlay/sys-apps/shadow/shadow-4.13-r4.ebuild @@ -21,7 +21,7 @@ SRC_URI+=" verify-sig? ( https://github.com/shadow-maint/shadow/releases/downloa LICENSE="BSD GPL-2" # Subslot is for libsubid's SONAME. SLOT="0/4" -KEYWORDS="~alpha amd64 arm arm64 ~hppa ~ia64 ~loong ~m68k ~mips ppc ppc64 ~riscv ~s390 sparc x86" +KEYWORDS="~alpha amd64 ~arm arm64 hppa ~ia64 ~loong ~m68k ~mips ~ppc ppc64 ~riscv ~s390 ~sparc ~x86" IUSE="acl audit bcrypt cracklib nls pam selinux skey split-usr su xattr" # Taken from the man/Makefile.am file. LANGS=( cs da de es fi fr hu id it ja ko pl pt_BR ru sv tr zh_CN zh_TW ) @@ -30,22 +30,24 @@ REQUIRED_USE="?? ( cracklib pam )" COMMON_DEPEND=" virtual/libcrypt:= - acl? ( sys-apps/acl:0= ) - audit? ( >=sys-process/audit-2.6:0= ) - cracklib? ( >=sys-libs/cracklib-2.7-r3:0= ) + acl? ( sys-apps/acl:= ) + audit? ( >=sys-process/audit-2.6:= ) + cracklib? ( >=sys-libs/cracklib-2.7-r3:= ) nls? ( virtual/libintl ) - pam? ( sys-libs/pam:0= ) - skey? ( sys-auth/skey:0= ) + pam? ( sys-libs/pam:= ) + skey? ( sys-auth/skey:= ) selinux? ( - >=sys-libs/libselinux-1.28:0= - sys-libs/libsemanage:0= + >=sys-libs/libselinux-1.28:= + sys-libs/libsemanage:= ) - xattr? ( sys-apps/attr:0= ) + xattr? ( sys-apps/attr:= ) " -DEPEND="${COMMON_DEPEND} +DEPEND=" + ${COMMON_DEPEND} >=sys-kernel/linux-headers-4.14 " -RDEPEND="${COMMON_DEPEND} +RDEPEND=" + ${COMMON_DEPEND} !