diff options
Diffstat (limited to 'meta-openbmc-mods/meta-common/recipes-extended')
5 files changed, 243 insertions, 0 deletions
diff --git a/meta-openbmc-mods/meta-common/recipes-extended/pam/libpam/CVE-2024-22365.patch b/meta-openbmc-mods/meta-common/recipes-extended/pam/libpam/CVE-2024-22365.patch new file mode 100644 index 000000000..781101372 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-extended/pam/libpam/CVE-2024-22365.patch @@ -0,0 +1,55 @@ +From 031bb5a5d0d950253b68138b498dc93be69a64cb Mon Sep 17 00:00:00 2001 +From: Matthias Gerstner <matthias.gerstner@suse.de> +Date: Wed, 27 Dec 2023 14:01:59 +0100 +Subject: [PATCH] pam_namespace: protect_dir(): use O_DIRECTORY to prevent + local DoS situations + +Without O_DIRECTORY the path crawling logic is subject to e.g. FIFOs +being placed in user controlled directories, causing the PAM module to +block indefinitely during `openat()`. + +Pass O_DIRECTORY to cause the `openat()` to fail if the path does not +refer to a directory. + +With this the check whether the final path element is a directory +becomes unnecessary, drop it. +--- + modules/pam_namespace/pam_namespace.c | 18 +----------------- + 1 file changed, 1 insertion(+), 17 deletions(-) + +diff --git a/modules/pam_namespace/pam_namespace.c b/modules/pam_namespace/pam_namespace.c +index 2528cff86..f72d67189 100644 +--- a/modules/pam_namespace/pam_namespace.c ++++ b/modules/pam_namespace/pam_namespace.c +@@ -1201,7 +1201,7 @@ static int protect_dir(const char *path, mode_t mode, int do_mkdir, + int dfd = AT_FDCWD; + int dfd_next; + int save_errno; +- int flags = O_RDONLY; ++ int flags = O_RDONLY | O_DIRECTORY; + int rv = -1; + struct stat st; + +@@ -1255,22 +1255,6 @@ static int protect_dir(const char *path, mode_t mode, int do_mkdir, + rv = openat(dfd, dir, flags); + } + +- if (rv != -1) { +- if (fstat(rv, &st) != 0) { +- save_errno = errno; +- close(rv); +- rv = -1; +- errno = save_errno; +- goto error; +- } +- if (!S_ISDIR(st.st_mode)) { +- close(rv); +- errno = ENOTDIR; +- rv = -1; +- goto error; +- } +- } +- + if (flags & O_NOFOLLOW) { + /* we are inside user-owned dir - protect */ + if (protect_mount(rv, p, idata) == -1) { diff --git a/meta-openbmc-mods/meta-common/recipes-extended/pam/libpam_1.5.2.bb b/meta-openbmc-mods/meta-common/recipes-extended/pam/libpam_1.5.2.bb index 5197f1813..74a9c8579 100644 --- a/meta-openbmc-mods/meta-common/recipes-extended/pam/libpam_1.5.2.bb +++ b/meta-openbmc-mods/meta-common/recipes-extended/pam/libpam_1.5.2.bb @@ -25,6 +25,7 @@ SRC_URI = "${GITHUB_BASE_URI}/download/v${PV}/Linux-PAM-${PV}.tar.xz \ file://run-ptest \ file://pam-volatiles.conf \ file://CVE-2022-28321-0002.patch \ + file://CVE-2024-22365.patch \ " SRC_URI[sha256sum] = "e4ec7131a91da44512574268f493c6d8ca105c87091691b8e9b56ca685d4f94d" diff --git a/meta-openbmc-mods/meta-common/recipes-extended/shadow/shadow/CVE-2023-4641.patch b/meta-openbmc-mods/meta-common/recipes-extended/shadow/shadow/CVE-2023-4641.patch new file mode 100644 index 000000000..4b5891dd2 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-extended/shadow/shadow/CVE-2023-4641.patch @@ -0,0 +1,142 @@ +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(+) + +diff --git a/src/gpasswd.c b/src/gpasswd.c +index a43d9a5..f69eb85 100644 +--- a/src/gpasswd.c ++++ b/src/gpasswd.c +@@ -919,6 +919,7 @@ static void change_passwd (struct group *gr) + strzero (cp); + cp = getpass (_("Re-enter new password: ")); + if (NULL == cp) { ++ memzero (pass, sizeof pass); + exit (1); + } + +-- +2.25.1 + diff --git a/meta-openbmc-mods/meta-common/recipes-extended/shadow/shadow_%.bbappend b/meta-openbmc-mods/meta-common/recipes-extended/shadow/shadow_%.bbappend index 15fd63096..c3d1864a2 100644 --- a/meta-openbmc-mods/meta-common/recipes-extended/shadow/shadow_%.bbappend +++ b/meta-openbmc-mods/meta-common/recipes-extended/shadow/shadow_%.bbappend @@ -5,4 +5,5 @@ PAM_SRC_URI += "file://pam.d/login \ SRC_URI += " \ file://CVE-2023-29383_1.patch \ file://CVE-2023-29383_2.patch \ + file://CVE-2023-4641.patch \ " diff --git a/meta-openbmc-mods/meta-common/recipes-extended/xz/xz_5.4.4.bb b/meta-openbmc-mods/meta-common/recipes-extended/xz/xz_5.4.4.bb new file mode 100644 index 000000000..90f4c3d82 --- /dev/null +++ b/meta-openbmc-mods/meta-common/recipes-extended/xz/xz_5.4.4.bb @@ -0,0 +1,44 @@ +SUMMARY = "Utilities for managing LZMA compressed files" +HOMEPAGE = "https://tukaani.org/xz/" +DESCRIPTION = "XZ Utils is free general-purpose data compression software with a high compression ratio. XZ Utils were written for POSIX-like systems, but also work on some not-so-POSIX systems. XZ Utils are the successor to LZMA Utils." +SECTION = "base" + +# The source includes bits of PD, GPL-2.0, GPL-3.0, LGPL-2.1-or-later, but the +# only file which is GPL-3.0 is an m4 macro which isn't shipped in any of our +# packages, and the LGPL bits are under lib/, which appears to be used for +# libgnu, which appears to be used for DOS builds. So we're left with +# GPL-2.0-or-later and PD. +LICENSE = "GPL-2.0-or-later & GPL-3.0-with-autoconf-exception & LGPL-2.1-or-later & PD" +LICENSE:${PN} = "GPL-2.0-or-later" +LICENSE:${PN}-dev = "GPL-2.0-or-later" +LICENSE:${PN}-staticdev = "GPL-2.0-or-later" +LICENSE:${PN}-doc = "GPL-2.0-or-later" +LICENSE:${PN}-dbg = "GPL-2.0-or-later" +LICENSE:${PN}-locale = "GPL-2.0-or-later" +LICENSE:liblzma = "PD" + +LIC_FILES_CHKSUM = "file://COPYING;md5=c8ea84ebe7b93cce676b54355dc6b2c0 \ + file://COPYING.GPLv2;md5=b234ee4d69f5fce4486a80fdaf4a4263 \ + file://COPYING.GPLv3;md5=1ebbd3e34237af26da5dc08a4e440464 \ + file://COPYING.LGPLv2.1;md5=4fbd65380cdd255951079008b364516c \ + file://lib/getopt.c;endline=23;md5=2069b0ee710572c03bb3114e4532cd84 \ + " + +SRC_URI = "https://tukaani.org/xz/xz-${PV}.tar.gz" +SRC_URI[sha256sum] = "aae39544e254cfd27e942d35a048d592959bd7a79f9a624afb0498bb5613bdf8" +UPSTREAM_CHECK_REGEX = "xz-(?P<pver>\d+(\.\d+)+)\.tar" + +CACHED_CONFIGUREVARS += "gl_cv_posix_shell=/bin/sh" + +inherit autotools gettext + +PACKAGES =+ "liblzma" + +FILES:liblzma = "${libdir}/liblzma*${SOLIBS}" + +inherit update-alternatives +ALTERNATIVE_PRIORITY = "100" +ALTERNATIVE:${PN} = "xz xzcat unxz \ + lzma lzcat unlzma" + +BBCLASSEXTEND = "native nativesdk" |