In days of yore (Fri, 29 Mar 2024), Russ Allbery thus quoth: > Russ Allbery <r...@debian.org> writes: > > Sirius <sir...@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
