[PATCH RFC] gnu: glibc: Fix CVE-2023-4911.

  • Done
  • quality assurance status badge
Details
2 participants
  • Liliana Marie Prikler
  • Ludovic Courtès
Owner
unassigned
Submitted by
Liliana Marie Prikler
Severity
important
L
L
Liliana Marie Prikler wrote on 4 Oct 2023 21:27
(address . guix-patches@gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
b4b918de4fce8ab839b51740f2758dc13f9884d5.1696450898.git.liliana.prikler@gmail.com
* gnu/packages/patches/glibc-2.35-CVE-2023-4911.patch: New file.
* gnu/local.mk: Register it here.
* gnu/packages/base.scm (glibc/fixed): New variable.
(glibc): Use it as replacement.
---
Hi folks,

you might have heard about a little bad boi called CVE-2023-4911.
Stirred up some news recently. I've "backported" the fix that's
currently sleeping on glibc master to our current glibc; only a test
needed adjusting. I still have to verify that it works in a vm, but
it appears to be rebuilding more than I anticipated, so that might take
me some time.

Anyway, have at it in the meantime.

Cheers

gnu/local.mk | 1 +
gnu/packages/base.scm | 10 ++
.../patches/glibc-2.35-CVE-2023-4911.patch | 160 ++++++++++++++++++
3 files changed, 171 insertions(+)
create mode 100644 gnu/packages/patches/glibc-2.35-CVE-2023-4911.patch

Toggle diff (210 lines)
diff --git a/gnu/local.mk b/gnu/local.mk
index 83b5268c7e..4a2c635ce6 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1275,6 +1275,7 @@ dist_patch_DATA = \
%D%/packages/patches/glibc-CVE-2019-7309.patch \
%D%/packages/patches/glibc-CVE-2019-9169.patch \
%D%/packages/patches/glibc-CVE-2019-19126.patch \
+ %D%/packages/patches/glibc-2.35-CVE-2023-4911.patch \
%D%/packages/patches/glibc-allow-kernel-2.6.32.patch \
%D%/packages/patches/glibc-boot-2.16.0.patch \
%D%/packages/patches/glibc-boot-2.2.5.patch \
diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index c0813f7de0..2d8e9143cd 100644
--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -793,6 +793,7 @@ (define-public glibc
(package
(name "glibc")
(version "2.35")
+ (replacement glibc/fixed)
(source (origin
(method url-fetch)
(uri (string-append "mirror://gnu/glibc/glibc-" version ".tar.xz"))
@@ -1062,6 +1063,15 @@ (define-public glibc
(license lgpl2.0+)
(home-page "https://www.gnu.org/software/libc/")))
+(define glibc/fixed
+ (package
+ (inherit glibc)
+ (source
+ (origin (inherit (package-source glibc))
+ (patches
+ (append (search-patches "glibc-2.35-CVE-2023-4911.patch")
+ (origin-patches (package-source glibc))))))))
+
;; Define a variation of glibc which uses the default /etc/ld.so.cache, useful
;; in FHS containers.
(define-public glibc-for-fhs
diff --git a/gnu/packages/patches/glibc-2.35-CVE-2023-4911.patch b/gnu/packages/patches/glibc-2.35-CVE-2023-4911.patch
new file mode 100644
index 0000000000..d8044f064d
--- /dev/null
+++ b/gnu/packages/patches/glibc-2.35-CVE-2023-4911.patch
@@ -0,0 +1,160 @@
+From 1056e5b4c3f2d90ed2b4a55f96add28da2f4c8fa Mon Sep 17 00:00:00 2001
+From: Siddhesh Poyarekar <siddhesh@sourceware.org>
+Date: Tue, 19 Sep 2023 18:39:32 -0400
+Subject: [PATCH 1/1] tunables: Terminate if end of input is reached
+ (CVE-2023-4911)
+
+The string parsing routine may end up writing beyond bounds of tunestr
+if the input tunable string is malformed, of the form name=name=val.
+This gets processed twice, first as name=name=val and next as name=val,
+resulting in tunestr being name=name=val:name=val, thus overflowing
+tunestr.
+
+Terminate the parsing loop at the first instance itself so that tunestr
+does not overflow.
+
+This also fixes up tst-env-setuid-tunables to actually handle failures
+correct and add new tests to validate the fix for this CVE.
+
+Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
+Reviewed-by: Carlos O'Donell <carlos@redhat.com>
+---
+Backported to 2.35 by Liliana Marie Prikler <liliana.prikler@gmail.com>
+
+ NEWS | 5 +++++
+ elf/dl-tunables.c | 17 +++++++++-------
+ elf/tst-env-setuid-tunables.c | 37 +++++++++++++++++++++++++++--------
+ 3 files changed, 44 insertions(+), 15 deletions(-)
+
+Index: glibc-2.35/NEWS
+===================================================================
+--- glibc-2.35.orig/NEWS
++++ glibc-2.35/NEWS
+@@ -199,6 +199,11 @@ Security related changes:
+ corresponds to the / directory through an unprivileged mount
+ namespace. Reported by Qualys.
+
++ CVE-2023-4911: If a tunable of the form NAME=NAME=VAL is passed in the
++ environment of a setuid program and NAME is valid, it may result in a
++ buffer overflow, which could be exploited to achieve escalated
++ privileges. This flaw was introduced in glibc 2.34.
++
+ The following bugs are resolved with this release:
+
+ [12889] nptl: Race condition in pthread_kill
+Index: glibc-2.35/elf/dl-tunables.c
+===================================================================
+--- glibc-2.35.orig/elf/dl-tunables.c
++++ glibc-2.35/elf/dl-tunables.c
+@@ -187,11 +187,7 @@ parse_tunables (char *tunestr, char *val
+ /* If we reach the end of the string before getting a valid name-value
+ pair, bail out. */
+ if (p[len] == '\0')
+- {
+- if (__libc_enable_secure)
+- tunestr[off] = '\0';
+- return;
+- }
++ break;
+
+ /* We did not find a valid name-value pair before encountering the
+ colon. */
+@@ -251,9 +247,16 @@ parse_tunables (char *tunestr, char *val
+ }
+ }
+
+- if (p[len] != '\0')
+- p += len + 1;
++ /* We reached the end while processing the tunable string. */
++ if (p[len] == '\0')
++ break;
++
++ p += len + 1;
+ }
++
++ /* Terminate tunestr before we leave. */
++ if (__libc_enable_secure)
++ tunestr[off] = '\0';
+ }
+ #endif
+
+Index: glibc-2.35/elf/tst-env-setuid-tunables.c
+===================================================================
+--- glibc-2.35.orig/elf/tst-env-setuid-tunables.c
++++ glibc-2.35/elf/tst-env-setuid-tunables.c
+@@ -52,6 +52,8 @@ const char *teststrings[] =
+ "glibc.malloc.perturb=0x800:not_valid.malloc.check=2:glibc.malloc.mmap_threshold=4096",
+ "glibc.not_valid.check=2:glibc.malloc.mmap_threshold=4096",
+ "not_valid.malloc.check=2:glibc.malloc.mmap_threshold=4096",
++ "glibc.malloc.mmap_threshold=glibc.malloc.mmap_threshold=4096",
++ "glibc.malloc.check=2",
+ "glibc.malloc.garbage=2:glibc.maoc.mmap_threshold=4096:glibc.malloc.check=2",
+ "glibc.malloc.check=4:glibc.malloc.garbage=2:glibc.maoc.mmap_threshold=4096",
+ ":glibc.malloc.garbage=2:glibc.malloc.check=1",
+@@ -70,6 +72,8 @@ const char *resultstrings[] =
+ "glibc.malloc.perturb=0x800:glibc.malloc.mmap_threshold=4096",
+ "glibc.malloc.mmap_threshold=4096",
+ "glibc.malloc.mmap_threshold=4096",
++ "glibc.malloc.mmap_threshold=glibc.malloc.mmap_threshold=4096",
++ "",
+ "",
+ "",
+ "",
+@@ -89,6 +93,8 @@ test_child (int off)
+
+ if (val != NULL)
+ printf ("[%d] Unexpected GLIBC_TUNABLES VALUE %s\n", off, val);
++ else
++ printf ("[%d] GLIBC_TUNABLES environment variable absent\n", off);
+
+ return 1;
+ #else
+@@ -117,21 +123,26 @@ do_test (int argc, char **argv)
+ if (ret != 0)
+ exit (1);
+
+- exit (EXIT_SUCCESS);
++ /* Special return code to make sure that the child executed all the way
++ through. */
++ exit (42);
+ }
+ else
+ {
+- int ret = 0;
+-
+ /* Spawn tests. */
+ for (int i = 0; i < array_length (teststrings); i++)
+ {
+ char buf[INT_BUFSIZE_BOUND (int)];
+
+- printf ("Spawned test for %s (%d)\n", teststrings[i], i);
++ printf ("[%d] Spawned test for %s\n", i, teststrings[i]);
+ snprintf (buf, sizeof (buf), "%d\n", i);
++ fflush (stdout);
+ if (setenv ("GLIBC_TUNABLES", teststrings[i], 1) != 0)
+- exit (1);
++ {
++ printf (" [%d] Failed to set GLIBC_TUNABLES: %m", i);
++ support_record_failure ();
++ continue;
++ }
+
+ int status = support_capture_subprogram_self_sgid (buf);
+
+@@ -139,9 +150,14 @@ do_test (int argc, char **argv)
+ if (WEXITSTATUS (status) == EXIT_UNSUPPORTED)
+ return EXIT_UNSUPPORTED;
+
+- ret |= status;
++ if (WEXITSTATUS (status) != 42)
++ {
++ printf (" [%d] child failed with status %d\n", i,
++ WEXITSTATUS (status));
++ support_record_failure ();
++ }
+ }
+- return ret;
++ return 0;
+ }
+ }
+

base-commit: e71864793021051cff35597abd59bb2d5649977d
--
2.41.0
L
L
Liliana Marie Prikler wrote on 5 Oct 2023 07:46
(address . 66348@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
ef2b25db2d6cf606c2e22bcf9bc7fbbb9aba197d.camel@gmail.com
Am Mittwoch, dem 04.10.2023 um 21:27 +0200 schrieb Liliana Marie
Prikler:
Toggle quote (15 lines)
> * gnu/packages/patches/glibc-2.35-CVE-2023-4911.patch: New file.
> * gnu/local.mk: Register it here.
> * gnu/packages/base.scm (glibc/fixed): New variable.
> (glibc): Use it as replacement.
> ---
> Hi folks,
>
> you might have heard about a little bad boi called CVE-2023-4911.
> Stirred up some news recently.  I've "backported" the fix that's
> currently sleeping on glibc master to our current glibc; only a test
> needed adjusting.  I still have to verify that it works in a vm, but
> it appears to be rebuilding more than I anticipated, so that might
> take me some time.
>
> Anyway, have at it in the meantime.
Confirmed in a VM that su no longer segfaults with this.

Cheers
L
L
Ludovic Courtès wrote on 7 Oct 2023 00:00
control message for bug #66348
(address . control@debbugs.gnu.org)
87cyxrza0z.fsf@gnu.org
severity 66348 important
quit
L
L
Ludovic Courtès wrote on 7 Oct 2023 00:00
(address . control@debbugs.gnu.org)
87bkdbza0w.fsf@gnu.org
tags 66348 + security
quit
L
L
Ludovic Courtès wrote on 7 Oct 2023 00:24
Re: bug#66348: [PATCH RFC] gnu: glibc: Fix CVE-2023-4911.
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . 66348@debbugs.gnu.org)
87ttr3xucv.fsf@gnu.org
Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:

Toggle quote (5 lines)
> * gnu/packages/patches/glibc-2.35-CVE-2023-4911.patch: New file.
> * gnu/local.mk: Register it here.
> * gnu/packages/base.scm (glibc/fixed): New variable.
> (glibc): Use it as replacement.

I’ve tested it and it LGTM.

I found a bug where the grafted libreoffice ends up indirectly referring
to the broken libc in addition to the fixed one:

Toggle snippet (16 lines)
$ ./pre-inst-env guix build libreoffice
/gnu/store/1v6kgw1nrccc67yqlm1pzic1y32z63xb-libreoffice-7.5.4.2
$ guix gc -R /gnu/store/1v6kgw1nrccc67yqlm1pzic1y32z63xb-libreoffice-7.5.4.2|grep glibc-2.35
/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35
/gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35
$ ./pre-inst-env guix build libreoffice --no-grafts
/gnu/store/f5iibn55pm70icnk16hd4a8hwchicrvf-libreoffice-7.5.4.2
$ guix gc -R /gnu/store/f5iibn55pm70icnk16hd4a8hwchicrvf-libreoffice-7.5.4.2|grep glibc-2.35
/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35
$ guix graph -t references --path /gnu/store/1v6kgw1nrccc67yqlm1pzic1y32z63xb-libreoffice-7.5.4.2 /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35
/gnu/store/1v6kgw1nrccc67yqlm1pzic1y32z63xb-libreoffice-7.5.4.2
/gnu/store/y392yldk4pbk4z5q587bz5n61hzbcf4g-mariadb-10.10.2-dev
/gnu/store/cilkyfnc5fxmpviyypci3d2881ik3nih-mariadb-10.10.2-lib
/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35

Not a showstopper but we’ll need to investigate.

Another concern: we’ll be grafting every single package. It hurts
performance so we may want to “ungraft” in core-updates and get it
merged soon.

Thoughts?

Ludo’.
L
L
Liliana Marie Prikler wrote on 7 Oct 2023 00:56
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 66348@debbugs.gnu.org)
604d2287350e122980db76d624af03422a0b4ec6.camel@gmail.com
Am Samstag, dem 07.10.2023 um 00:24 +0200 schrieb Ludovic Courtès:
Toggle quote (36 lines)
> Hi Liliana,
>
> Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:
>
> > * gnu/packages/patches/glibc-2.35-CVE-2023-4911.patch: New file.
> > * gnu/local.mk: Register it here.
> > * gnu/packages/base.scm (glibc/fixed): New variable.
> > (glibc): Use it as replacement.
>
> I’ve tested it and it LGTM.
>
> I found a bug where the grafted libreoffice ends up indirectly
> referring to the broken libc in addition to the fixed one:
>
> --8<---------------cut here---------------start------------->8---
> $ ./pre-inst-env guix build libreoffice
> /gnu/store/1v6kgw1nrccc67yqlm1pzic1y32z63xb-libreoffice-7.5.4.2
> $ guix gc -R /gnu/store/1v6kgw1nrccc67yqlm1pzic1y32z63xb-libreoffice-
> 7.5.4.2|grep glibc-2.35
> /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35
> /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35
> $ ./pre-inst-env guix build libreoffice --no-grafts
> /gnu/store/f5iibn55pm70icnk16hd4a8hwchicrvf-libreoffice-7.5.4.2
> $ guix gc -R /gnu/store/f5iibn55pm70icnk16hd4a8hwchicrvf-libreoffice-
> 7.5.4.2|grep glibc-2.35
> /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35
> $ guix graph -t references --path
> /gnu/store/1v6kgw1nrccc67yqlm1pzic1y32z63xb-libreoffice-7.5.4.2
> /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35
> /gnu/store/1v6kgw1nrccc67yqlm1pzic1y32z63xb-libreoffice-7.5.4.2
> /gnu/store/y392yldk4pbk4z5q587bz5n61hzbcf4g-mariadb-10.10.2-dev
> /gnu/store/cilkyfnc5fxmpviyypci3d2881ik3nih-mariadb-10.10.2-lib
> /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35
> --8<---------------cut here---------------end--------------->8---
>
> Not a showstopper but we’ll need to investigate.
Eww.

Toggle quote (5 lines)
> Another concern: we’ll be grafting every single package.  It hurts
> performance so we may want to “ungraft” in core-updates and get it
> merged soon.
>
> Thoughts?
Is core-updates ready otherwise? If not, we might want to do a quick
"ungrafting" branch before that.

Cheers
L
L
Ludovic Courtès wrote on 11 Oct 2023 23:24
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . 66348@debbugs.gnu.org)
874jiwrgwn.fsf_-_@gnu.org
Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:

Toggle quote (2 lines)
> Am Samstag, dem 07.10.2023 um 00:24 +0200 schrieb Ludovic Courtès:

[...]

Toggle quote (8 lines)
>> Another concern: we’ll be grafting every single package.  It hurts
>> performance so we may want to “ungraft” in core-updates and get it
>> merged soon.
>>
>> Thoughts?
> Is core-updates ready otherwise? If not, we might want to do a quick
> "ungrafting" branch before that.

To be clear: I think this patch should go to ‘master’, we’d rather not
wait too long.

As for ungrafting, yeah, maybe we’ll need a branch, but let’s discuss
that separately.

Thanks,
Ludo’.
L
L
Liliana Marie Prikler wrote on 12 Oct 2023 06:58
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 66348-done@debbugs.gnu.org)
01782ce35e0c6c5d07392060761298980a46e628.camel@gmail.com
Am Mittwoch, dem 11.10.2023 um 23:24 +0200 schrieb Ludovic Courtès:
Toggle quote (18 lines)
> Hi Liliana,
>
> Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:
>
> > Am Samstag, dem 07.10.2023 um 00:24 +0200 schrieb Ludovic Courtès:
>
> [...]
>
> > > Another concern: we’ll be grafting every single package.  It
> > > hurts performance so we may want to “ungraft” in core-updates and
> > > get it merged soon.
> > >
> > > Thoughts?
> > Is core-updates ready otherwise?  If not, we might want to do a
> > quick "ungrafting" branch before that.
>
> To be clear: I think this patch should go to ‘master’, we’d rather
> not wait too long.
Okay. Pushed to master now.

Toggle quote (2 lines)
> As for ungrafting, yeah, maybe we’ll need a branch, but let’s discuss
> that separately.
Sure.

Cheers
Closed
?