There is a chance Fedora is not affected according to the following analysis:
Quoting:
=====
If those conditions check, the payload is injected into the source tree. We have not analyzed this payload in detail. Here are the main things we know:
The payload only activates if the running program has the process name /usr/bin/sshd. This means that systems that put sshd in /usr/sbin or another folder are not vulnerable. This further suspects targeting systemd systems due to their usrmerge initiative putting all binaries in /usr/bin.
The payload only activates if the running program has the process name /usr/bin/sshd. This means that systems that put sshd in /usr/sbin or another folder are not vulnerable. This further suspects targeting systemd systems due to their usrmerge initiative putting all binaries in /usr/bin.
=====
We have the patch from https://github.com/openssh/openssh-portable/pull/375 applied, BTW.
On Fri, Mar 29, 2024 at 10:59 PM Richard W.M. Jones <rjones@xxxxxxxxxx> wrote:
On Fri, Mar 29, 2024 at 04:46:54PM -0500, Michael Catanzaro wrote:
> On Fri, Mar 29 2024 at 04:10:53 PM -05:00:00, Michael Catanzaro
> <mcatanzaro@xxxxxxxxxx> wrote:
> >OK, I am going to ask Product Security to edit their blog post to
> >remove the incorrect information. I will CC you on that request.
>
> Or maybe I should rephrase this as a "request for clarification,"
> because maybe they know something that we don't. E.g. the Ars
> article [1] says
>
> "The build environment on Fedora 40, for example, contains
> incompatibilities that prevent the injection from correctly
> occurring. Fedora 40 has now reverted to the 5.4.x versions of xz
> Utils."
>
> [1] https://arstechnica.com/security/2024/03/backdoor-found-in-widely-used-linux-utility-breaks-encrypted-ssh-connections/
Yeah that's just a confused report. This is how it actually happened:
(1) We built 5.6.0 for Fedora 40 & 41. Jia Tan was very insistent in
emails that we should update.
(2) We got reports later of a valgrind test failure. I also saw it
myself in my own projects that use liblzma. We notified Jia Tan of
this.
(3) Since the valgrind failure pointed to something with ifuncs, using
'./configure --disable-ifuncs' was used to fix this in F40 & F41.
(4) xz 5.6.1 was released with a fix for the valgrind failure.
(5) Fedora 40 was now in beta so we kept 5.6.0 + --disable-ifuncs.
Fedora 41 was updated to 5.6.1 (enabling ifuncs again).
And now with the benefit of hindsight ...
In step (1) we worked in good faith with upstream. Given how
obfuscated the injection is, it's very unlikely we would have found
the problem even if we'd spent days inspecting the tarball. (And the
initial step of injection is *not* in git, so forget about reviewing
git commits.)
The valgrind failure (2) was caused by a bug in the back door.
Disabling ifuncs in (3) disabled the back door, because I think it
relies on ifuncs to do its malware, but in any case the obfuscated
injection script explicitly skips injection if ifuncs are disabled.
Step (4) fixed the back door valgrind failure.
The Fedora 40 beta freeze in (5) meant we got lucky for F40, not so
much for F41.
Rich.
> Now, that's a secondary source, and I'm not confident if it is true,
> but perhaps Product Security had time to analyze the build logs
> before publishing and found something that we don't know about.
> Richard, what do you think?
>
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit
--
_______________________________________________
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
Dmitry Belyavskiy
-- _______________________________________________ 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
