Excellent succinct breakdown of the xz mess, from an OpenBSD developer • Hacker News Board

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#21

Post by o11c » Fri, Apr 05, 2024, 4:49 PM UTC

logicprog wrote: post #15

waynesonfire wrote: post #5

> Liblzma ends up dynamically linked to sshd because of a systemd-related extension added by many Linux packagers that pulls in liblzma as an unrelated dependency kinda wish this was unpacked a bit more, why exactly is a service executable dynamically linking to a library without using any of its symbols or functions, because of systemd. and a follow up if some openbsd folks can comment. over the years i've read abou…

> kinda wish this was unpacked a bit more, why exactly is a service executable dynamically linking to a library without using any of its symbols or functions, because of systemd. If I recall correctly based on what I've read about this — I believe from the original mailing list post that noticed the vulnerability — it's because under certain circumstances in order to enable certain functionality you might want sshd t…

> even though there are at least two other libraries that implement just the communication functionality and are actually designed for non-systemd programs to use.

The important question is: if one of those libraries is used, and then something else pulls in `libsystemd`, will they conflict?

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#22

Post by tedunangst » Fri, Apr 05, 2024, 4:53 PM UTC

lenerdenator wrote: post #13

AwaAwa wrote: post #10

Earlier quoted context omitted.

> The syntax error is a single period '.' as the first character on an otherwise empty line of C code. I believe the point is that given this context, it could/should not be construed as a typo.

I take it they're not forcing contributors to lint code, then?

Have you tried running lint on a configure.ac or CMakeLists.txt file?

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#23

Post by tedunangst » Fri, Apr 05, 2024, 4:57 PM UTC

waynesonfire wrote: post #5

> Liblzma ends up dynamically linked to sshd because of a systemd-related extension added by many Linux packagers that pulls in liblzma as an unrelated dependency kinda wish this was unpacked a bit more, why exactly is a service executable dynamically linking to a library without using any of its symbols or functions, because of systemd. and a follow up if some openbsd folks can comment. over the years i've read abou…

There's very little you can do to limit the scope of a backdoor in sshd. If sshd can't do anything, you wouldn't be able to do anything after logging in either, which wouldn't be very useful.

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#24

Post by brenoguim » Fri, Apr 05, 2024, 4:58 PM UTC

AwaAwa wrote: post #10

brenoguim wrote: post #9

> It does not plausibly pass for a typo because no typical editing glitch will leave a '.' character there. I would certainly attribute that to a typo if I was reviewing the code.

> The syntax error is a single period '.' as the first character on an otherwise empty line of C code. I believe the point is that given this context, it could/should not be construed as a typo.

For those using editors with mouse, it's very easy to add a character anywhere. Doesn't matter the place.

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#25

Post by ip26 » Fri, Apr 05, 2024, 5:00 PM UTC

brenoguim wrote: post #9

> It does not plausibly pass for a typo because no typical editing glitch will leave a '.' character there. I would certainly attribute that to a typo if I was reviewing the code.

The point is that under casual review & in isolation, it's not hard to accept as a typo, but under closer review and knowing what we know now, it's almost certainly part of the attack.

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#26

Post by [deleted] » Fri, Apr 05, 2024, 5:04 PM UTC

throwanem wrote: post #16

deskamess wrote: post #6

There really is an exception to every rule. "Do not attribute to malice that which can be adequately explained by neglect, ignorance or incompetence" and then you come across: > The stage 0 shell snippet looks at first glance like a plausible part of > the poorly readable autoconf/automake tooling.

None of those adequately explain these commits. This is no exception to Hanlon's razor.

[deleted]

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#27

Post by rany_ » Fri, Apr 05, 2024, 5:10 PM UTC

brenoguim wrote: post #9

> It does not plausibly pass for a typo because no typical editing glitch will leave a '.' character there. I would certainly attribute that to a typo if I was reviewing the code.

We only know it's malicious in hindsight. If I was Lasse (original xz maintainer) I could have easily thought it was an innocent typo and that's the point. If it was more convoluted like zero-width Unicode character or misspelling of variable names, it'll be less plausible IMO.

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#28

Post by jethro_tell » Fri, Apr 05, 2024, 5:12 PM UTC

deskamess wrote: post #6

There really is an exception to every rule. "Do not attribute to malice that which can be adequately explained by neglect, ignorance or incompetence" and then you come across: > The stage 0 shell snippet looks at first glance like a plausible part of > the poorly readable autoconf/automake tooling.

Also, given the context its clearly malice.

If there was one commit with a stray period that disabled the sandbox, sure, might be a typo.

But the other stuff where they're unpacking specific byte ranges from multiple places in the test files, that's not an accident.

Viewed as a whole, it would be extremely hard to view this as "adequately explained by neglect, ignorance or incompetence"

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#29

Post by xorcist » Fri, Apr 05, 2024, 5:20 PM UTC

amiga386 wrote: post #18

waynesonfire wrote: post #5

> Liblzma ends up dynamically linked to sshd because of a systemd-related extension added by many Linux packagers that pulls in liblzma as an unrelated dependency kinda wish this was unpacked a bit more, why exactly is a service executable dynamically linking to a library without using any of its symbols or functions, because of systemd. and a follow up if some openbsd folks can comment. over the years i've read abou…

sshd is started by systemd. systemd has several ways of starting programs and waiting until they're "ready" before starting other programs that depend on them: Type=oneshot, simple, exec, forking, dbus, notify, ... A while back, several distro maintainers found problems with using Type=exec (?) and chose Type=notify instead. When sshd is ready, it notifies systemd. How do you notify systemd? You send a datagram to sy…

This seems like a clear case of premature optimization. During the three decades sshd has existed I have never seen a real world situation where the equivalent of Type=exec was not enough.

The time window where sshd is started and not yet ready to receive connections is short, and clients will have a connection timeout orders of magnitude larger. The notify functionality is more relevant for things like Java middleware processes and clients that lack the functionality to poll and wait. Under most situations none of this is relevant for sshd. These patches solve a problem very few people have.

If you really have this problem, the systemd readiness is far from enough to solve the problem. The readiness is sent too early and there could still be permission problems that would cause sshd to be ready but the connection to fail. Even more relevant is local firewall rules that are completely out of scope for a readiness check!

Polling for readiness is the only robust way.

Re: Excellent succinct breakdown of the xz mess, from an OpenBSD developer

#30

Post by francescovv » Fri, Apr 05, 2024, 5:23 PM UTC

throwanem wrote: post #16

deskamess wrote: post #6

There really is an exception to every rule. "Do not attribute to malice that which can be adequately explained by neglect, ignorance or incompetence" and then you come across: > The stage 0 shell snippet looks at first glance like a plausible part of > the poorly readable autoconf/automake tooling.

None of those adequately explain these commits. This is no exception to Hanlon's razor.

Hanlon's razor is useful to curb one's paranoia, but it is far from being a universal rule.

In fact, malice and incompetence are not necessarily mutually exclusive.

This very incident shows several instances where "Jia Tan" is being arguably incompetent, in addition to being clearly malicious: unintended breakage by adding extra space between "return" and "is_arch_extension_supported"; several redundant checks for `uname` == "Linux"; botched payload, so "test files" had to be replaced, with pretty fishy explanation; rather inefficient/slow GOT parsing, list goes on...