* On 2024 01 Apr 14:01 -0500, Andy Smith wrote: > Hi, > > On Mon, Apr 01, 2024 at 03:33:37AM -0500, Nate Bargmann wrote: > > From what I have read, lzma is not a direct dependency of openssh. It > > turns out that it lzma is a dependency of libsystemd and that > > relationship affected openssh. > > > > Jacob Bachmeyer in analysis > > (https://lists.gnu.org/archive/html/automake/2024-04/msg00000.html) > > says: > > > > Lastly on this topic, some of the blame for this needs to fall on the > > systemd maintainers and their "katamari" architecture. There is no good > > reason for notifications of daemon startup to pull in liblzma, but using > > libsystemd for that purpose does exactly that, and ended up getting > > xz-utils targeted as a means of getting to sshd without the OpenSSH > > maintainers noticing. > > > > End quote. > > In my view a great example of the "people other than me just need to > get good" fallacy merged with the group of people predisposed to > hate systemd. AIUI, systemd already has patches to limit the use of lzma to only dlopen when needed: https://lwn.net/Articles/967399/ This action apparently predates this incident and was made for other considerations. More than anything, I think this shows in the future some hard decisions will need to made to prevent unrelated code affecting other code through linked intermediate code. AIUI, that would be a fundamental change to our systems that would likely break (assuming) a lot of software. > It could have been any direct or indirect dependency of sshd here. Or any other daemon but openssh is a very attractive target and systemd as a service manager is a defacto standard. > I'm quite sure almost none of them have the required resources and > processes to detect something like this. Until now, who anticipated this? I'm sure there are security researchers who have and it's likely that I'm not well-read enough on this topic to have seen it discussed. How many people did it occur to that when A links to B and B links to C that C can create a vulnerability in A? That is what I understand happened here. The social part where Jia Tan (individual, group, state actor?) gains commit privileges, which in a small project are seldom reviewed as some level of trust has been established before granting such privileges, and over time begins the process of introducing compromising code bit by bit. It is curious that any of the compromise was committed when other parts were added at the creation of the release tarball. Perhaps it was determined that a two-prong approach would garner less suspicion. I have also read that this entity began a campaign to get the latest lzma release into distributions quickly. That kind of behavior will now raise suspicions due to this event. When a developer believes that distributions should update ASAP they likely better have a CVE issue at hand or expect their work to be more carefully audited. > I think anyone buying into systemd-blaming here needs to have a good > hard look at their biases. Which is another part of this massive > social problem. It's such a distraction. And here we are in a thread > that started with a bug in a 30+ year old setgid binary. We all carry biases. I've no idea of Jacob Bachmeyer's bias toward systemd, if any, other than "katamari" apparently refers to a Japanese video game I know absolutely nothing about. How that relates, good or bad, I have no idea. I will say that I have been satisfied with its implementation over several Debian releases but that is because I trust Debian more than upstream. Upstream systemd has not done itself many favors over the years WRT community interaction. I think that developers would be wise not to follow the systemd project's path with their own endeavors. I do find systemd useful and even enable some of the optional features on my Debian systems. It works well enough and the commonality of configuration style between the optional components is helpful. Unavoidably, systemd is going to get a bit of bad press here simply because of its service manager role that enabled the C creating a vulnerability in A scenario. The upshot is that patches to openssh-portable applied by Debian might move away from linking in libsystemd if I read that LWN thread correctly. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
Attachment:
signature.asc
Description: PGP signature