On 2024-03-30 02:37, Richard W.M. Jones wrote:
(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_decr...@....plt 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to