From 7f6e0ec904c4c9ba2db969c8131d3db9514943a1 Mon Sep 17 00:00:00 2001 From: Sylvain Beucler Date: Fri, 18 Apr 2025 15:46:55 +0200 Subject: [PATCH] Import Debian changes 1:4.8.1-1+deb11u1 shadow (1:4.8.1-1+deb11u1) bullseye-security; urgency=high . * Non-maintainer upload by the LTS Security Team. * CVE-2023-4641: When asking for a new password, shadow-utils asks the password twice. If the password fails on the second attempt, shadow-utils fails in cleaning the buffer used to store the first entry. This may allow an attacker with enough access to retrieve the password from the memory. (Closes: #1051062) * CVE-2023-29383: It is possible to inject control characters into fields provided to the SUID program chfn (change finger). Although it is not possible to exploit this directly (e.g., adding a new user fails because \n is in the block list), it is possible to misrepresent the /etc/passwd file when viewed. (Closes: #1034482) * Add Salsa-CI configuration. * Silence lintian error that can't be fixed after freeze. --- debian/changelog | 18 ++++ debian/passwd.lintian-overrides | 2 + debian/patches/CVE-2023-29383.patch | 83 ++++++++++++++++ debian/patches/CVE-2023-4641.patch | 143 ++++++++++++++++++++++++++++ debian/patches/series | 3 + debian/salsa-ci.yml | 13 +++ 6 files changed, 262 insertions(+) create mode 100644 debian/patches/CVE-2023-29383.patch create mode 100644 debian/patches/CVE-2023-4641.patch create mode 100644 debian/salsa-ci.yml diff --git a/debian/changelog b/debian/changelog index c3e011b3..1fa5618e 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,21 @@ +shadow (1:4.8.1-1+deb11u1) bullseye-security; urgency=high + + * Non-maintainer upload by the LTS Security Team. + * CVE-2023-4641: When asking for a new password, shadow-utils asks the + password twice. If the password fails on the second attempt, + shadow-utils fails in cleaning the buffer used to store the first + entry. This may allow an attacker with enough access to retrieve the + password from the memory. (Closes: #1051062) + * CVE-2023-29383: It is possible to inject control characters into + fields provided to the SUID program chfn (change finger). Although it + is not possible to exploit this directly (e.g., adding a new user + fails because \n is in the block list), it is possible to misrepresent + the /etc/passwd file when viewed. (Closes: #1034482) + * Add Salsa-CI configuration. + * Silence lintian error that can't be fixed after freeze. + + -- Sylvain Beucler Fri, 18 Apr 2025 15:46:55 +0200 + shadow (1:4.8.1-1) unstable; urgency=medium * debian/default/useradd: Fix typo DHSELL -> DSHELL (Closes: #897028) diff --git a/debian/passwd.lintian-overrides b/debian/passwd.lintian-overrides index 9f05b121..630d69c9 100644 --- a/debian/passwd.lintian-overrides +++ b/debian/passwd.lintian-overrides @@ -4,3 +4,5 @@ passwd: setuid-binary usr/bin/chsh 4755 root/root passwd: setgid-binary usr/bin/expiry 2755 root/shadow passwd: setuid-binary usr/bin/gpasswd 4755 root/root passwd: setuid-binary usr/bin/passwd 4755 root/root +# Fixed in a0f09c4de7ad35b1a7c64cbe7024c9b7236ad491 but would add a Recommend: during LTS +passwd: missing-depends-on-sensible-utils sensible-editor usr/sbin/vipw diff --git a/debian/patches/CVE-2023-29383.patch b/debian/patches/CVE-2023-29383.patch new file mode 100644 index 00000000..6a7f5111 --- /dev/null +++ b/debian/patches/CVE-2023-29383.patch @@ -0,0 +1,83 @@ +Origin: https://github.com/shadow-maint/shadow/commit/e5905c4b84d4fb90aefcd96ee618411ebfac663d +Origin: https://github.com/shadow-maint/shadow/commit/2eaea70111f65b16d55998386e4ceb4273c19eb4 +Reviewed-by: Sylvain Beucler +Last-Update: 2025-04-15 + +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(-) + +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(-) + +Index: shadow-4.8.1/lib/fields.c +=================================================================== +--- shadow-4.8.1.orig/lib/fields.c ++++ shadow-4.8.1/lib/fields.c +@@ -44,9 +44,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) +@@ -60,23 +60,22 @@ int valid_field (const char *field, cons + + /* 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 some non-printable characters */ +- for (cp = field; '\0' != *cp; cp++) { +- if (!isprint (*cp)) { +- err = 1; +- break; +- } +- } +- } +- + return err; + } + diff --git a/debian/patches/CVE-2023-4641.patch b/debian/patches/CVE-2023-4641.patch new file mode 100644 index 00000000..7f250272 --- /dev/null +++ b/debian/patches/CVE-2023-4641.patch @@ -0,0 +1,143 @@ +Origin: https://github.com/shadow-maint/shadow/commit/65c88a43a23c2391dcc90c0abda3e839e9c57904 +Reviewed-by: Sylvain Beucler +Last-Update: 2025-04-15 + +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 +--- + src/gpasswd.c | 1 + + 1 file changed, 1 insertion(+) + +Index: shadow-4.8.1/src/gpasswd.c +=================================================================== +--- shadow-4.8.1.orig/src/gpasswd.c ++++ shadow-4.8.1/src/gpasswd.c +@@ -911,6 +911,7 @@ static void change_passwd (struct group + for (retries = 0; retries < RETRIES; retries++) { + cp = getpass (_("New Password: ")); + if (NULL == cp) { ++ memzero (pass, sizeof pass); + exit (1); + } + diff --git a/debian/patches/series b/debian/patches/series index 68dc397a..a2e49043 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -14,3 +14,6 @@ 508_nologin_in_usr_sbin 505_useradd_recommend_adduser 501_commonio_group_shadow + +CVE-2023-4641.patch +CVE-2023-29383.patch diff --git a/debian/salsa-ci.yml b/debian/salsa-ci.yml new file mode 100644 index 00000000..7530140c --- /dev/null +++ b/debian/salsa-ci.yml @@ -0,0 +1,13 @@ +--- +# LTS/ELTS CI + +include: +- https://salsa.debian.org/lts-team/pipeline/raw/master/recipes/bullseye.yml + +# These didn't work before LTS, not attempting to fix after freeze +#blhc: +# allow_failure: true + +# https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/275 +piuparts: + allow_failure: true