Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

marc.info

Post reply on HN
Print view View original

31–40 of 54 posts

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

#31

Post by narrator »

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 lets every single first degree murderer off the hook, or any other of the many crimes where you have to establish intent to convict.

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

#32

Post by zokier »

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…

> But obviously you need a library to implement actually speaking system's protocol

That is overstatement. The docs have basic self-contained example how to implement the notification without libraries, its 50 lines, majority of which is just error handling:

https://www.freedesktop.org/software/systemd/man/devel/sd_no...

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

#33

Post by zokier »

o11c wrote: post #21
logicprog wrote: post #15

Earlier quoted context omitted.

> 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?

Why would they? There isn't any magic in libsystemd, its just a normal c lib

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

#34

Post by ryanjshaw »

> the build-to-host.m4 macro package that ships as part of GNU gettext was replaced by a modified version that was copied into the release tarball

Am I correct in concluding that this backdoor might have been picked up sooner if the practice of shipping tarballs of source releases was dropped in favour of running builds straight off a repo tag?

I've setup and worked with many build pipelines in the .NET world over nearly 20 years and we manage fine without the concept of a source release tarball, but I realise C dev is more complex so I'm probably missing something?

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

#35

Post by ksherlock »

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.

ed man! Ed uses a single . line to end input. You actually can't enter a single '.' (because that wound end your input) but "I was using vi and must have dropped into ex mode or something" on the surface sounds reasonable.

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

#36

Post by throwanem »

narrator wrote: post #31
throwanem wrote: post #16

Earlier quoted context omitted.

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

Hanlon's razor lets every single first degree murderer off the hook, or any other of the many crimes where you have to establish intent to convict.

It is a rule-of-thumb heuristic, not a law.

Even if this weren't the case, your claim would remain specious. "Establish intent" and "justify attribution to malice" are the same thing said two ways.

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

#37

Post by zokier »

xorcist wrote: post #29
amiga386 wrote: post #18

Earlier quoted context omitted.

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 middlewa…

> The readiness is sent too early

What makes you say that? The readiness notification is sent after the sshd has opened the listen socket, it literally is accepting connections at that point.

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

#38

Post by NekkoDroid »

rany_ wrote: post #27
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.

The thing is, if anyone would have actually realized it (other than Jai) it would have been hopefully fixed. Like... no one would just see that and say "well, must have been a typo" and just leaves it.

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

#39

Post by NekkoDroid »

zokier wrote: post #32
logicprog wrote: post #15

Earlier quoted context omitted.

> 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…

> But obviously you need a library to implement actually speaking system's protocol That is overstatement. The docs have basic self-contained example how to implement the notification without libraries, its 50 lines, majority of which is just error handling: https://www.freedesktop.org/software/systemd/man/devel/sd_no...

The example was only recently added (like 1-2 days ago). Before that it was only really explained and said it was stable (and guarnteed as stable API).

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

#40

Post by cryptonector »

> 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.

Lots of dependencies -> bad. Reducing dependencies will sometimes necessitate open-coding things, which too can be bad.

But what's interesting here is that if you're trying to find a good place to insert a backdoor, all you need to do is analyze the dependency graphs of targets of interest looking for ones which might be vulnerable to compromise via social engineering or other vectors. We should do our own such analysis looking for places that need to be watched better or removed.

Post reply on HN