(3) We should have a "security path", like "critical path". sshd is linked to a lot of libraries:
I really don't want to start a systemd thread, but... the xz, lz4, and zstd libraries are pulled in by libsystemd, merely so that sshd can call "sd_notify" (https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-7.4p1-systemd.patch), which raises a couple of questions.
The first one that comes to mind is: Is the increased attack surface incurred by linking to these additional libraries worth the value provided by calling "sd_notify", or should that patch be dropped to improve sshd security?
The second is: Is libsystemd too large? I could very easily be misreading it, but it looks like at least some of src/libsystemd/sd-journal is used by journald, including the compression bits. Do those really belong in libsystemd? If they need to be shared components, could the journald components be split out to reduce the size of libsystemd? (That is, to avoid linking to the compression libs?)
Moving on to a broader topic:
The write up describing the back door indicates that the
malicious xz library "changes the value of
RSA_public_decrypt@xxxxxxx to point to its own code." So the back
door has pointed one of the symbols that should point to a page
mapped to OpenSSL's libcrypto.so.3 to a page mapped to
liblzma.so.5, instead.
Would it be possible to audit the value of a process's symbols at
runtime to look for this kind of shenanigans? Could this type of
auditing be added to functional tests or rpminspect?
-- _______________________________________________ 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
