diff options
Diffstat (limited to 'sys-apps/shadow/files')
4 files changed, 0 insertions, 306 deletions
diff --git a/sys-apps/shadow/files/shadow-4.13-CVE-2023-29383.patch b/sys-apps/shadow/files/shadow-4.13-CVE-2023-29383.patch deleted file mode 100644 index 49868ba67c96..000000000000 --- a/sys-apps/shadow/files/shadow-4.13-CVE-2023-29383.patch +++ /dev/null @@ -1,100 +0,0 @@ -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?= <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(-) - -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/sys-apps/shadow/files/shadow-4.13-configure-clang16.patch b/sys-apps/shadow/files/shadow-4.13-configure-clang16.patch deleted file mode 100644 index 4e703db93a6c..000000000000 --- a/sys-apps/shadow/files/shadow-4.13-configure-clang16.patch +++ /dev/null @@ -1,38 +0,0 @@ -https://github.com/shadow-maint/shadow/commit/a281f241b592aec636d1b93a99e764499d68c7ef -https://github.com/shadow-maint/shadow/pull/595 - -From a281f241b592aec636d1b93a99e764499d68c7ef Mon Sep 17 00:00:00 2001 -From: Florian Weimer <fweimer@redhat.com> -Date: Mon, 21 Nov 2022 11:52:45 +0100 -Subject: [PATCH] Fix HAVE_SHADOWGRP configure check - -The missing #include <gshadow.h> causes the configure check to fail -spuriously, resulting in HAVE_SHADOWGRP not being defined even -on systems that actually have sgetsgent (such as current glibc). ---- a/configure.ac -+++ b/configure.ac -@@ -116,6 +116,10 @@ if test "$ac_cv_header_shadow_h" = "yes"; then - ac_cv_libc_shadowgrp, - AC_RUN_IFELSE([AC_LANG_SOURCE([ - #include <shadow.h> -+ #ifdef HAVE_GSHADOW_H -+ #include <gshadow.h> -+ #endif -+ int - main() - { - struct sgrp *sg = sgetsgent("test:x::"); - ---- a/configure -+++ b/configure -@@ -15684,6 +15684,10 @@ else $as_nop - /* end confdefs.h. */ - - #include <shadow.h> -+ #ifdef HAVE_GSHADOW_H -+ #include <gshadow.h> -+ #endif -+ int - main() - { - struct sgrp *sg = sgetsgent("test:x::"); diff --git a/sys-apps/shadow/files/shadow-4.13-password-leak.patch b/sys-apps/shadow/files/shadow-4.13-password-leak.patch deleted file mode 100644 index 25b5ec39c5f8..000000000000 --- a/sys-apps/shadow/files/shadow-4.13-password-leak.patch +++ /dev/null @@ -1,135 +0,0 @@ -https://github.com/shadow-maint/shadow/commit/65c88a43a23c2391dcc90c0abda3e839e9c57904 - -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> ---- 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/sys-apps/shadow/files/shadow-4.13-usermod-prefix-gid.patch b/sys-apps/shadow/files/shadow-4.13-usermod-prefix-gid.patch deleted file mode 100644 index 50cbe699d15e..000000000000 --- a/sys-apps/shadow/files/shadow-4.13-usermod-prefix-gid.patch +++ /dev/null @@ -1,33 +0,0 @@ -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 <floppym@gentoo.org> -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 <floppym@gentoo.org> ---- 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"), |