[PATCH] WIP patches for recently-known hurd security vulnerabilities

  • Open
  • quality assurance status badge
Details
4 participants
  • janneke
  • Ludovic Courtès
  • Maxim Cournoyer
  • Maxime Devos
Owner
unassigned
Submitted by
Maxime Devos
Severity
normal
M
M
Maxime Devos wrote on 20 Sep 2021 12:40
(address . guix-patches@gnu.org)
727b3d7ec511589ab714874d6648ee4afa458e3c.camel@telenet.be
Hi,

I've tried to patch the glibc package for the problems noted at

I've found two recent patches (glibc-hurd-proc-reauth.patch and
glibc-hurd-sendmsg-SCM_CREDS.patch) that appeared relevant. I tried
to patch our glibc package with those patches.

The modified tarball builds fine for --system=x86_64-linux, but not
for --system=i586-gnu (tested with ./pre-inst-env guix build hello
--system=i586-gnu). Any idea what's happening here?

Greetings,
Maxime.
Attachment: 0001-WIP-gnu-glibc-New-security-patches.patch
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYUhlMBccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7iWrAQD1ktyb6uKCWa+zNN7qsHV47ZtY
koQkU0lwuQP5hE8MDAD+PLRxrxmKLWcnZHtikmzVyas8E/3+ias1pe5UIRoX9A4=
=jKWR
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 21 Sep 2021 15:50
control message for bug #50698
(address . control@debbugs.gnu.org)
87mto6javq.fsf@gnu.org
tags 50698 + security
quit
L
L
Ludovic Courtès wrote on 4 Oct 2021 15:52
Re: bug#50698: [PATCH] WIP patches for recently-known hurd security vulnerabilities
(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 50698@debbugs.gnu.org)
87pmskq4mc.fsf@gnu.org
Hi Maxime,

Maxime Devos <maximedevos@telenet.be> skribis:

Toggle quote (11 lines)
> I've tried to patch the glibc package for the problems noted at
> <https://lists.gnu.org/archive/html/bug-hurd/2021-08/msg00007.html>;.
>
> I've found two recent patches (glibc-hurd-proc-reauth.patch and
> glibc-hurd-sendmsg-SCM_CREDS.patch) that appeared relevant. I tried
> to patch our glibc package with those patches.
>
> The modified tarball builds fine for --system=x86_64-linux, but not
> for --system=i586-gnu (tested with ./pre-inst-env guix build hello
> --system=i586-gnu). Any idea what's happening here?

Thanks for looking into it!

Toggle quote (28 lines)
> From cdf38fbfcba4c87777d7ba2175f08e877dafe86a Mon Sep 17 00:00:00 2001
> From: Maxime Devos <maximedevos@telenet.be>
> Date: Mon, 13 Sep 2021 11:23:21 +0200
> Subject: [PATCH] WIP gnu: glibc: New security patches.
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> The existence of the vulnerabilities was noted at
> <https://lists.gnu.org/archive/html/bug-hurd/2021-08/msg00007.html>.
>
> TODO: check if these are all necessary packages for glibc.
> TODO: why does the glibc tarball build for --system=x86_64-linux but not
> for --system=i586-gnu?
>
> Build error:
> ‘patching file hurd/hurdinit.c
> Hunk #1 FAILED at 177.
> 1 out of 1 hunk FAILED -- saving rejects to file hurd/hurdinit.c.rej’
>
> but this file isn't modified by the new patches!
>
> * gnu/local.mk (dist_patch_DATA): Register new patches.
> * gnu/packages/base.scm (glibc)[replacement]: Register replacement.
> (glibc/fixed): New variable.
> * gnu/packages/patches/glibc-hurd-proc-reauth.patch: New file.
> * gnu/packages/patches/glibc-hurd-sendmsg-SCM_CREDS.patch.

[...]

Toggle quote (20 lines)
> --- a/gnu/packages/base.scm
> +++ b/gnu/packages/base.scm
> @@ -706,6 +706,7 @@ the store.")
> (package
> (name "glibc")
> (version "2.31")
> + (replacement glibc/fixed)
> (source (origin
> (method url-fetch)
> (uri (string-append "mirror://gnu/glibc/glibc-" version ".tar.xz"))
> @@ -966,6 +967,12 @@ with the Linux kernel.")
> (license lgpl2.0+)
> (home-page "https://www.gnu.org/software/libc/")))
>
> +(define glibc/fixed
> + (package-with-extra-patches
> + glibc
> + (search-patches "glibc-hurd-sendmsg-SCM_CREDS.patch"
> + "glibc-hurd-proc-reauth.patch")))

Instead of a replacement, which makes no sense on GNU/Linux, could you
add a conditional phase for (hurd-target?) that applies the patches?

(On ‘core-updates’ (or ‘-frozen’?) we will apply patches
unconditionally.)

Not answering your initial question, but maybe the problem will vanish
if you do things this way, who knows. :-)

Toggle quote (4 lines)
> +++ b/gnu/packages/patches/glibc-hurd-proc-reauth.patch
> @@ -0,0 +1,114 @@
> +Index: glibc-2.31/hurd/hurdsig.c

Please add a comment explaining what this patch does, what its status
is, with a link to upstream discussions.

Thank you!

Ludo’.
M
M
Maxime Devos wrote on 4 Oct 2021 17:00
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 50698@debbugs.gnu.org)
bf180129911ad9c0accc9a17c497bae8bd482ad2.camel@telenet.be
Ludovic Courtès schreef op ma 04-10-2021 om 15:52 [+0200]:
Toggle quote (9 lines)
> > +(define glibc/fixed
> > + (package-with-extra-patches
> > + glibc
> > + (search-patches "glibc-hurd-sendmsg-SCM_CREDS.patch"
> > + "glibc-hurd-proc-reauth.patch")))
>
> Instead of a replacement, which makes no sense on GNU/Linux, could you
> add a conditional phase for (hurd-target?) that applies the patches?

A replacement would be useless on GNU/Linux, but harmless.
Adding a phase (conditional on (hurd-target?)) to glibc
calling 'patch' on these patches would be possible, but would
cause a world-rebuild for GNU/Hurd (though not for GNU/Linux).

Because i586-gnu is ‘experimental and under development’
(according to (guix)GNU Distribution), I suppose the (partial)
world-rebuild is acceptable here?

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYVsXHBccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7nMxAP45FVW/LChPC/crnjAUqF5djayB
CJoATzWVpQt0G+JhqQD/esgcdRHI8B+016W+I60ThcW9b3jaujHRG+m3jmBmsQw=
=J3lD
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 8 Oct 2021 09:40
(name . Maxime Devos)(address . maximedevos@telenet.be)(address . 50698@debbugs.gnu.org)
87wnmo55if.fsf@gnu.org
Maxime Devos <maximedevos@telenet.be> skribis:

Toggle quote (12 lines)
> Ludovic Courtès schreef op ma 04-10-2021 om 15:52 [+0200]:
>> > +(define glibc/fixed
>> > + (package-with-extra-patches
>> > + glibc
>> > + (search-patches "glibc-hurd-sendmsg-SCM_CREDS.patch"
>> > + "glibc-hurd-proc-reauth.patch")))
>>
>> Instead of a replacement, which makes no sense on GNU/Linux, could you
>> add a conditional phase for (hurd-target?) that applies the patches?
>
> A replacement would be useless on GNU/Linux, but harmless.

Performance-wise it would have an impact on GNU/Linux because we’d end
up grafting the new glibc on each and every package.

Toggle quote (8 lines)
> Adding a phase (conditional on (hurd-target?)) to glibc
> calling 'patch' on these patches would be possible, but would
> cause a world-rebuild for GNU/Hurd (though not for GNU/Linux).
>
> Because i586-gnu is ‘experimental and under development’
> (according to (guix)GNU Distribution), I suppose the (partial)
> world-rebuild is acceptable here?

Yes, I think it’s okay to have a world-rebuild limited to i586-gnu, even
more so that the “world” is pretty small there. :-)
(It essentially stops at ‘util-linux’ currently.)

Thanks,
Ludo’.
M
M
Maxim Cournoyer wrote on 11 Nov 07:50 +0100
Re: [bug#50698] [PATCH] WIP patches for recently-known hurd security vulnerabilities
(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
875xoub6xi.fsf@gmail.com
Hi Janneke,

Would you know if this series is still relevant, following your recent
series that update most of the Hurd components?

--
Thanks,
Maxim
J
J
janneke wrote on 11 Nov 08:57 +0100
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87r07iw6bi.fsf@gnu.org
Maxim Cournoyer writes:

Hey Maxim,

Toggle quote (3 lines)
> Would you know if this series is still relevant, following your recent
> series that update most of the Hurd components?

Yes. Debian is still carrying these agains their glibc:


I have no idea about their status or why Debian hasn't upstreamed them.

Maybe now is a good time to add these to glibc/hurd (it seems we still
have a hook for a custom glibc library in place, yay!).

Would you like to rebase/create a patch for the hurd-team branch?

Greetings,
Janneke

--
Janneke Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com| Avatar® https://AvatarAcademy.com
?
Your comment

Commenting via the web interface is currently disabled.

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

To respond to this issue using the mumi CLI, first switch to it
mumi current 50698
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