Richard W.M. Jones wrote on Sat, Mar 30, 2024 at 09:37:44AM +0000: > In the xz case this wouldn't have been enough, it turns out we would > also have to delete m4/build-to-host.m4, which then autoreconf > regenerates. I don't fully understand why that is. I'm not 100% sure about the theory, but it looks like `autoreconf -fi` looks at the 'serial' in the first line of the script. The one bundled in the xz sources was marked very high: # build-to-host.m4 serial 30 But the one in the system (as of f39) is only 'serial 1'. Artificially lowering the serial back to 0 in the file and running `autoreconf -fi` again properly reinstall the one from the system over it, but anything higher will keep it... So if we want to go this route, we should remove the full m4 dir, but unfortunately I've seen quite a few projects that depend on non-standard m4 scripts so we'll need to fix these as we go... (At which point I'd suggest it's probably faster to convert it all to meson or another new shiny, and saner, build system, but getting upstreams to agree will be fun) > (2) We should discourage gnulib as much as possible. > [...] > In the xz case it was a gnulib-derived script which was modified to do > the initial injection (original: > https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/build-to-host.m4;h=f928e9ab403b3633e3d1d974abcf478e65d4b0aa;hb=HEAD). (Honestly I did compare the backdoored script and the real one this morning and I would be hard pressed to say if either is backdoored just looking at either version... Admitedly it was 3AM when I looked at it, but I don't think it's just a late hour problem) > (3) We should have a "security path", like "critical path". > > sshd is linked to a lot of libraries: > > /lib64/libaudit.so.1 audit-libs > /lib64/libc.so.6 glibc > /lib64/libcap-ng.so.0 libcap-ng > /lib64/libcap.so.2 libcap > /lib64/libcom_err.so.2 libcom_err > /lib64/libcrypt.so.2 libxcrypt > /lib64/libcrypto.so.3 openssl-libs > /lib64/libeconf.so.0 libeconf > /lib64/libgcc_s.so.1 libgcc > /lib64/libgssapi_krb5.so.2 krb5-libs > /lib64/libk5crypto.so.3 krb5-libs > /lib64/libkeyutils.so.1 keyutils-libs > /lib64/libkrb5.so.3 krb5-libs > /lib64/libkrb5support.so.0 krb5-libs > /lib64/liblz4.so.1 lz4-libs > /lib64/liblzma.so.5 xz-libs > /lib64/libm.so.6 glibc > /lib64/libpam.so.0 pam-libs > /lib64/libpcre2-8.so.0 pcre2 > /lib64/libresolv.so.2 glibc > /lib64/libselinux.so.1 libselinux > /lib64/libsystemd.so.0 systemd-libs > /lib64/libz.so.1 zlib / zlib-ng > /lib64/libzstd.so.1 zstd > > Should we have a higher level of attention to these packages? We > already have "critical path", but that's a broad category now. These > seem like they are "security path" packages, an intentionally small > subset associated with very secure services which are enabled by > default. Before making each of these safer we should make sshd not link with so many things in the first place. On oss-security, Solar Designer made a lot of good points about it (around here: https://www.openwall.com/lists/oss-security/2024/03/29/27 , but the full thread is interesting) But that's specific to sshd, and this problem could happen with any network-facing service: I guess sshd is a juciy target because it runs as root (whereas backdooring e.g. nginx would run as www user and not be as interesting), but in practice that could be bad enough. (hm, well, your point about 'enabled by default' strikes home though - we definitely could pay more attention to these first) -- Dominique Martinet | Asmadeus -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
