[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
?
Your comment

This issue is archived.

To comment on this conversation send an email to 66348@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 66348
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch