Re: xz backdoor
In days of yore (Fri, 29 Mar 2024), Russ Allbery thus quoth:
> Russ Allbery <rra@debian.org> writes:
> > Sirius <sirius@trudheim.com> writes:
>
> >> This is quite actively discussed on Fedora lists.
> >> https://www.openwall.com/lists/oss-security/2024/
> >> https://www.openwall.com/lists/oss-security/2024/03/29/4
>
> >> Worth taking a look if action need to be taken on Debian.
>
> > The version of xz-utils was reverted to 5.4.5 in unstable yesterday by
> > the security team and migrated to testing today. Anyone running an
> > unstable or testing system should urgently upgrade.
>
> I think the big open question we need to ask now is what exactly the
> backdoor (or, rather, backdoors; we know there were at least two versions
> over time) did. If they only target sshd, that's one thing, and we have a
> bound on systems possibly affected. But liblzma is linked directly or
> indirectly into all sorts of things such as, to give an obvious example,
> apt-get. A lot of Debian developers use unstable or testing systems. If
> the exploit was also exfiltrating key material, backdooring systems that
> didn't use sshd, etc., we have a lot more cleanup to do.
>
> I think this question can only be answered with reverse-engineering of the
> backdoors, and I personally don't have the skills to do that.
>From what I understand and have read, there is someone that will take a
look at reverse-engineering the .o and figure out what it did. The fact
the exploit looked for /usr/bin/sshd as argv[0] suggests it was targeted
at providing a backdoor into systems via just sshd. To what end, I guess
we will find out. Botnet would be the least worrisome IMHO.
A striking aspect is that this exploit was slow and methodical. This was
no ordinary script-kiddie doing things for giggles. I do wonder what will
shake out of this, but this level of patience and planning does raise
questions.
As you point out, the compression libraries are a weak link. I would think
the authentication and crypto libraries are as well. In this instance,
maybe both Debian and Fedora can breathe a sigh of relief that things got
caught when they did and that the remediation is not man-months or
man-years worth of effort. That said, someone plowing this amount of time
into planting just the one exploit may have other projects sized up where
they can try again.
I have seen discussion about shifting away from the whole auto(re)conf
tooling to CMake or Meson with there being a reasonable drawback to CMake.
Is that something being discussed within Debian as well?
--
Kind regards,
/S
Reply to: