Compare commits

...

1 Commits

Author SHA1 Message Date
Sylvain Beucler
7f6e0ec904 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.
2025-04-18 17:29:39 +02:00
6 changed files with 262 additions and 0 deletions

18
debian/changelog vendored
View File

@@ -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 <beuc@debian.org> 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)

View File

@@ -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

83
debian/patches/CVE-2023-29383.patch vendored Normal file
View File

@@ -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 <beuc@debian.org>
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?= <cgzones@googlemail.com>
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;
}

143
debian/patches/CVE-2023-4641.patch vendored Normal file
View File

@@ -0,0 +1,143 @@
Origin: https://github.com/shadow-maint/shadow/commit/65c88a43a23c2391dcc90c0abda3e839e9c57904
Reviewed-by: Sylvain Beucler <beuc@debian.org>
Last-Update: 2025-04-15
From 65c88a43a23c2391dcc90c0abda3e839e9c57904 Mon Sep 17 00:00:00 2001
From: Alejandro Colomar <alx@kernel.org>
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 <alx@kernel.org>
Cc: Serge Hallyn <serge@hallyn.com>
Cc: Iker Pedrosa <ipedrosa@redhat.com>
Cc: Seth Arnold <seth.arnold@canonical.com>
Cc: Christian Brauner <christian@brauner.io>
Cc: Balint Reczey <rbalint@debian.org>
Cc: Sam James <sam@gentoo.org>
Cc: David Runge <dvzrv@archlinux.org>
Cc: Andreas Jaeger <aj@suse.de>
Cc: <~hallyn/shadow@lists.sr.ht>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
---
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);
}

View File

@@ -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

13
debian/salsa-ci.yml vendored Normal file
View File

@@ -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