diff options
author | V3n3RiX <venerix@koprulu.sector> | 2023-06-17 07:43:56 +0100 |
---|---|---|
committer | V3n3RiX <venerix@koprulu.sector> | 2023-06-17 07:43:56 +0100 |
commit | b978efa000250668b2befa4e2cc96e0afa137611 (patch) | |
tree | 0c561efed9b15c17a9d3ef926443f35c58dfb48c /sys-apps/shadow/files | |
parent | fa5e8e92d94ea9de5d49a1f5ad19abf7272503d0 (diff) |
gentoo auto-resync : 17:06:2023 - 07:43:56
Diffstat (limited to 'sys-apps/shadow/files')
-rw-r--r-- | sys-apps/shadow/files/shadow-4.13-password-leak.patch | 135 | ||||
-rw-r--r-- | sys-apps/shadow/files/shadow-4.13-usermod-prefix-gid.patch | 33 |
2 files changed, 168 insertions, 0 deletions
diff --git a/sys-apps/shadow/files/shadow-4.13-password-leak.patch b/sys-apps/shadow/files/shadow-4.13-password-leak.patch new file mode 100644 index 000000000000..25b5ec39c5f8 --- /dev/null +++ b/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 <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 new file mode 100644 index 000000000000..50cbe699d15e --- /dev/null +++ b/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 <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"), |