glibc: update 2.33 -> 2.36

[niclas]

No description provided.

[donald]

Attempted install on a test system made bee abort during install and resulted in an unusable system where no external command could be executed. First problem: /lib64/ld-linux-x86-64.so.2 -> ld-2.36.so was updated before ld-2.36.so was installed. Not sure, why this didn't happened on previous glibc updated. Anyway, even after this was fixed, no could be executed with some "stack protection" nonsense, probably a result of a 2.33 2.36 mix in the system.

Recovered via clusterd ---exec and static binaries from busybox over nfs to untar the old glibc package.

[niclas]

Warning: Not all programs which were compiled on a new glibc system can be run on an old glibc system. I compiled my terminal (st) on inbetweenmove (glibc 2.36) and couldn't start it on machdoch (glibc 2.33).

machdoch ~> st
st: /lib/libc.so.6: version `GLIBC_2.34' not found (required by st)

[donald]

I've rebuild the glibc-2.36-0.x86_64 package.

I've removed glibc-locales-2.33-0.x86_64 and force-installed glibc-2.36-0.x86_64 on inbetweenmove,

[pmenzel]

(Debian sid/unstable just upgraded libc6 to 2.35-1, and the change-log mentions Bug 17645 - RFE: Improve performance of dynamic loader for deeply nested DSO dependencies. from 2014 (glibc-2.11) is fixed in that version. Hopefully it decreases the load time of some applications.)

@niclas, any help needed?

[donald]

Set okeanos to nodist and did sudo bee remove glibc-locales-2.33-0.x86_64 && sudo bee update -f glibc-2.36-0.x86_64 there.

[donald]

Also now nodist and installed on wtf.

[donald]

(on wtf) :

2022-10-07T14:08:31+02:00 wtf saslauthd[23297]: PAM unable to dlopen(/usr/lib/security/pam_unix.so): /lib/libnsl.so.1: undefined symbol: __lll_lock_wake_private, version GLIBC_PRIVATE
2022-10-07T14:08:31+02:00 wtf saslauthd[23297]: PAM adding faulty module: /usr/lib/security/pam_unix.so
2022-10-07T14:08:31+02:00 wtf saslauthd[23297]: DEBUG: auth_pam: pam_authenticate failed: Module is unknown
2022-10-07T14:08:31+02:00 wtf saslauthd[23297]: do_auth         : auth failure: [user=molgen] [service=imap] [realm=] [mech=pam] [reason=PAM auth error]

"change password" web interface not working currently. Guess, this is from glibc update and would be bad on the imap server, too

[donald]

Also affects cron:
2022-10-07T14:14:01+02:00 wtf crond[28381]: PAM unable to dlopen(/usr/lib/security/pam_unix.so): /lib/libnsl.so.1: undefined symbol: __lll_lock_wake_private, version GLIBC_PRIVATE

[donald]

libnsl.so.1 is from the glibc package. The symbol _lll_lock_wake_private is defined in libc.so.6 version 2.36 but not in version 2.33. If a long running process has the old libc mapped and dlopens a new binary, which uses that symbol, this will fail. The dlopen() is done by Linux-PAM in this case.

[donald]

wtf back to dist.

[donald]

okeanos (update glibc 27.9. 10:00) :

[Sep27 04:54] conftest[42691]: segfault at 0 ip 00007f62ddc46f01 sp 00007ffd5dc1ec58 error 4 in libc-2.33.so[7f62ddb0c000+148000]
[  +0.014534] Code: 48 29 f9 83 f9 3f 76 73 48 89 d1 f3 a4 c3 80 fa 10 73 17 80 fa 08 73 27 80 fa 04 73 33 80 fa 01 77 3b 72 05 0f b6 0e 88 0f c3 <c5> fa 6f 06 c5 fa 6f 4c 16 f0 c5 fa 7f 07 c5 fa 7f 4c 17 f0 c3 48
[Sep27 05:10] conftest[70766]: segfault at 0 ip 00007fd3b4756f01 sp 00007ffcac568ee8 error 4 in libc-2.33.so[7fd3b461c000+148000]
[  +0.015089] Code: 48 29 f9 83 f9 3f 76 73 48 89 d1 f3 a4 c3 80 fa 10 73 17 80 fa 08 73 27 80 fa 04 73 33 80 fa 01 77 3b 72 05 0f b6 0e 88 0f c3 <c5> fa 6f 06 c5 fa 6f 4c 16 f0 c5 fa 7f 07 c5 fa 7f 4c 17 f0 c3 48
[Sep27 05:48] conftest[112653]: segfault at 0 ip 00007fce2a98cf01 sp 00007ffd747a4988 error 4 in libc-2.33.so[7fce2a852000+148000]
[  +0.014734] Code: 48 29 f9 83 f9 3f 76 73 48 89 d1 f3 a4 c3 80 fa 10 73 17 80 fa 08 73 27 80 fa 04 73 33 80 fa 01 77 3b 72 05 0f b6 0e 88 0f c3 <c5> fa 6f 06 c5 fa 6f 4c 16 f0 c5 fa 7f 07 c5 fa 7f 4c 17 f0 c3 48
[Sep27 08:00] conftest[108513]: segfault at 0 ip 00007fbfb8f84f01 sp 00007ffc98040ac8 error 4 in libc-2.33.so[7fbfb8e4a000+148000]
[  +0.014655] Code: 48 29 f9 83 f9 3f 76 73 48 89 d1 f3 a4 c3 80 fa 10 73 17 80 fa 08 73 27 80 fa 04 73 33 80 fa 01 77 3b 72 05 0f b6 0e 88 0f c3 <c5> fa 6f 06 c5 fa 6f 4c 16 f0 c5 fa 7f 07 c5 fa 7f 4c 17 f0 c3 48
[Sep27 08:16] conftest[59766]: segfault at 0 ip 00007fc5d58c3f01 sp 00007ffe6643cfa8 error 4 in libc-2.33.so[7fc5d5789000+148000]
[  +0.016297] Code: 48 29 f9 83 f9 3f 76 73 48 89 d1 f3 a4 c3 80 fa 10 73 17 80 fa 08 73 27 80 fa 04 73 33 80 fa 01 77 3b 72 05 0f b6 0e 88 0f c3 <c5> fa 6f 06 c5 fa 6f 4c 16 f0 c5 fa 7f 07 c5 fa 7f 4c 17 f0 c3 48
[Sep27 08:42] wget[77225]: segfault at 0 ip 0000000000000000 sp 00007ffeb2dc7648 error 14 in wget[400000+70000]
[  +0.011588] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
[  +0.685029] wget[78261]: segfault at 0 ip 0000000000000000 sp 00007ffee18aa488 error 14 in wget[400000+70000]
[  +0.011605] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
[  +0.957857] Core dump to |/bin/false pipe failed
[Oct 1 18:13] conftest[78401]: segfault at 7ffc00ebe330 ip 00007f796244d45f sp 00007ffc3aebe1a0 error 4 in libc.so.6[7f79623a4000+152000]
[  +0.016719] Code: 3c 3a 74 17 84 c0 74 1e 0f 1f 00 0f b6 43 01 48 83 c3 01 84 c0 74 0f 3c 3a 75 f0 84 c0 74 07 c6 03 00 48 83 c3 01 48 8b 45 00 <0f> b6 00 83 e8 2b a8 fd 0f 85 63 01 00 00 80 3b 00 75 5e 31 c0 48

So the good thing is, that one segfault stopped with the update. But another single one appeared after the update. The IP is in _nss_files_parse_pwent.

[niclas]

@donald since the currently installed Linux-PAM-version is 4 years old we could try if updating it, solves that issue. I made a pull request for that update, so you can test it.

[donald]

But I suspect, that the pam_unix.so (from the glibc-2.36-0 bee package) is incompatible with libc.so (from the glibc-2.33-0 bee package, locked into memory of several processes). Although pam.so does the logic and dlopen()s pam_unix.so, I don't see, what it could do about it.

[thomas]

Hmm, to avoid some confusion pam_unix.so is part of Linux-PAM, no deal in the glibc. But I also doubt that just updating Linux-PAM wil resolve the issue, but I would give it a try.

My proposal would be to rebuild Linux-PAM against an installed glibc-2.36, and then update/distribute the both of them.

[donald]

Hmm, to avoid some confusion pam_unix.so is part of Linux-PAM, no deal in the glibc

Oh, right,. I was confused. Its not pam_unix.so which lives in the glibc package, but libnsl.so.1, which is required by pam_unix.so. The result is the same, though. pam_unix.so can't be loaded, because libnsl.so.1 from the new glibc package is incompatible to the old glibc library in memory.

And libnsl (getpwent etc.) itself dlopens() the plugings in /lib/libnss, e.g. /usr/lib/libnss_files-2.33.so, which also is from glibc. We might problems even without Linux PAM involved. Maybe this is the cause of the _nss_files_parse_pwent segfault mentioned above.

[donald]

@donald since the currently installed Linux-PAM-version is 4 years old we could try if updating it, solves that issue. I made a pull request for that update, so you can test it.

That might have helped, because pam_unix.so from a build of that version references libnsl.so.2 from the libnsl-1.3.0-1.x86_64 package instead of libnsl.so.1 from the glibc package. So it looked like it broke the circular loop.

However, a running saslauth which already was used, has /usr/lib/libpam.so.0.84.2 in its memory. If Linux-PAM is updated, the new pam_unix.so is incompatible with the old libpam.so in memory.

2022-10-11T13:50:45+02:00 sigusr2 saslauthd[338]: PAM unable to dlopen(/usr/lib/security/pam_unix.so): /usr/lib/libpam.so.0: version `LIBPAM_MODUTIL_1.3.2' not found (required by /usr/lib/security/pam_unix.so)

What a mess.

[pmenzel]

1. Buffer overflow in svcunix_create with long pathnames (CVE-2022-23218) (https://sourceware.org/bugzilla/show_bug.cgi?id=CVE-2022-23219)
2. buffer overflow in sunrpc clnt_create (CVE-2022-23219) (https://sourceware.org/bugzilla/show_bug.cgi?id=CVE-2022-23219)

Both were fixed in glibc 2.35. From Debian’s security tracker:

CVE-2022-23218

The deprecated compatibility function svcunix_create in the sunrpc module of the GNU C Library (aka glibc) through 2.34 copies its path argument on the stack without validating its length, which may result in a buffer overflow, potentially resulting in a denial of service or (if an application is not built with a stack protector enabled) arbitrary code execution.

CVE-2022-23219

The deprecated compatibility function clnt_create in the sunrpc module of the GNU C Library (aka glibc) through 2.34 copies its hostname argument on the stack without validating its length, which may result in a buffer overflow, potentially resulting in a denial of service or (if an application is not built with a stack protector enabled) arbitrary code execution.

[donald]

Userspace code can crash its userspace process, it doesn't even need a buffer overflow in glibc for that.

Do these two bugs have any meaning for us? Is any code using these calls with strings from another security domain?

[donald]

To be installed on mx64/deinemuddah, not on mx64old/deineommah