A backdoor in xz [LWN.net]

A backdoor in xz

Posted Mar 30, 2024 8:12 UTC (Sat) by DimeCadmium (subscriber, #157243)
In reply to: A backdoor in xz by rra
Parent article: A backdoor in xz

If it didn't actually start, then it shouldn't have forked off and backgrounded itself, which is how services notified the service manager that they had successfully started for literal decades before systemd came along.

to post comments

A backdoor in xz

Posted Mar 30, 2024 8:23 UTC (Sat) by mb (subscriber, #50428) [Link] (4 responses)

Yep, and it was broken all the time because everybody did it differently and slightly wrong, until systemd came along.
But let's not distract from the discussion: systemd ist *not* why this backdoor was possible. It could have been any other library. It could even have been any other server application. It's not restricted to sshd.

The real problem is that patches that have not been understood/reviewed have been applied.
This is a social problem. Not a technical one.

A backdoor in xz

Posted Mar 30, 2024 12:46 UTC (Sat) by stef70 (guest, #14813) [Link] (1 responses)

Indeed. We need to wait until the full analysis of the backdoor to be sure that no tool other than sshd was targeted.

On my Debian system, liblzma.so is linked in several programs and libraries. A lot are unrelated to systemd: grub, insmod, lvm, reboot, gimp, imagemagick, runlevel, ...

All of them are potential targets for that xz backdoor. For now, we have to wait for the full analysis. I am pretty optimistic that sshd was the main target because installing another backdoor on the system or calling "home" would significantly increase the probability or detection.

A backdoor in xz

Posted Mar 30, 2024 23:33 UTC (Sat) by brooksmoses (guest, #88422) [Link]

There is code in the exploit that would look for additional files in the "test" directory that matched specific byte patterns, and then extract a payload from them and execute it. There are currently no files matching those patterns -- so it certainly looks like this bit was designed as a capability to target additional programs simply by adding additional "test" files to the git repository.

[Reference: https://github.com/Midar/xz-backdoor-documentation/wiki#s... as of the time of this comment.]

A backdoor in xz

Posted Mar 31, 2024 1:25 UTC (Sun) by DimeCadmium (subscriber, #157243) [Link] (1 responses)

> Yep, and it was broken all the time because everybody did it differently and slightly wrong, until systemd came along.

Ah, okay. And how exactly do you believe that one methods of notifications is any more reliable at this than any other? They all rely on the software developer picking a good time to say "started".

> But let's not distract from the discussion: systemd ist *not* why this backdoor was possible

It absolutely is.

> It could have been any other library

But it wasn't. "Don't worry about our vulnerabilities, other people have vulnerabilities too!" "Don't worry about our bad design, other people have bad design too!"

A backdoor in xz

Posted Mar 31, 2024 9:22 UTC (Sun) by smurf (subscriber, #17840) [Link]

> They all rely on the software developer picking a good time to say "started".

They all rely on picking a good time that happens to *work*.

There are plenty of situations where, once you're *really* started, it's no longer possible to signal "OK I'm alive now" by double-forking.

Writing a PID file has its own class of race conditions, the handling of which I can guarantee most users of that method get fatally wrong.

And so on.

> "Don't worry about our vulnerabilities, other people have vulnerabilities too!" "Don't worry about our bad design, other people have bad design too!"

Don't blame the messenger. If linking to a library you don't strictly need *in your particular situation* is a "vulnerability" or "bad design" I can guarantee that 90+% of programs out there suffer from it.

A backdoor in xz

Posted Mar 30, 2024 9:53 UTC (Sat) by motk (subscriber, #51120) [Link]

Yeah, and it sucked. It sucked 35 years ago. It still sucks.

This whole thing has nothing to do with service management, and everything to do with large corporations relying on volunteers writing critical software apparently just for something to do.

A backdoor in xz

Posted Mar 30, 2024 16:58 UTC (Sat) by rra (subscriber, #99804) [Link] (2 responses)

> If it didn't actually start, then it shouldn't have forked off and backgrounded itself, which is how services notified the service manager that they had successfully started for literal decades before systemd came along.

I have run UNIX systems throughout those literal decades that you are talking about, and your faith in this half-assed, failure-prone mechanism is badly misplaced. I cannot count the number of ways I have seen this fail: the process does not actually start listening to the network until after the fork, the process starts listening before the fork but isn't really ready to accept connections because there is setup that has to be done after the fork, the process forks but doesn't fork twice and thus isn't properly reparented, the process didn't write a PID file and now you have no idea which process is actually running the service, the process did write a PID file and wrote the wrong PID to that file, you end up with multiple backgrounded copies of the same service running and interfering weirdly with each other... the list goes on.

We figured out that this was a bad way to run services by at least the early 2000s, when support for a foreground model with none of this self-daemonization nonsense badly copied into every service became widely available (and as someone who was managing UNIX systems all through that period, that was a delightful revelation). But you do not want to assume that the service is ready simply because the process has started. You need some mechanism for signaling that the service really has fully started, has allocated all of its resources, and is listening to network connections (if that is its job). Otherwise, you risk starting services that depend on it too soon.

Even upstart (the alternative preferred by some of the folks who disliked systemd) had a mechanism for doing this. (It was worse than systemd's, at least in my opinion.)

A backdoor in xz

Posted Mar 31, 2024 1:25 UTC (Sun) by DimeCadmium (subscriber, #157243) [Link] (1 responses)

So have I, and YOUR faith in systemd's half-assed, failure-prone mechanism is badly misplaced.

Please stop here

Posted Mar 31, 2024 1:45 UTC (Sun) by corbet (editor, #1) [Link]

We have managed to keep this conversation relatively free of systemd bashing, which is really not relevant to the discussion. Please don't do any more of it here.