fun, the new lib xz with systemd and ssh backdoor sounds linux specific

xz (XZ Utils) 5.4.4 liblzma 5.4.4 ftw!

rolling releases bite you, imho...

i like static os..

yeah, but ssh doesn't use it. systemd did.

i was reading that linux boxes that patch sshd to use logind to inform systemd are the ones vulnerable

no new features just correct current errors would be nice

Title: xz-utils backdoor situation · GitHub

we don't include the test bits (payload) in our import of it, and we don't use its build system

so even if there was a chance it wasn't linux specific

(it'd have to be a bit less stealthy to hit us)

supply chain attack pip python, java log4j

nothing new at this point

same old shit dog just a different day

hehe

smoke a bowl and drink a pint...

we need you to come in this easter weekend...

rennj: actually... this being a security bug in 3 layers deep code is novel

i'm simultaneously surprised but not at all that andres seems to be the first to detect it

(he's very good at what he does, which is... usually database stuff)

or more horrifying

all those checks, and unit tests

haha...reproducable builds

nix so easy to just roll back

ah, sounds like it also needs glibc

just another failure what i see.. ports/pkg..source..what diff..if your backdoored on github

that's a hell of an attack chain

makes me want to hang up the computer and grow edible lupins

Probably too late for that :P

[0x1eef], yes, I know the lupin supply chain in Canada is fully patented

Lol

I don't give a fuck

is there an order to zfs / nullfs mount in /etc/fstab? I have some zfs mounts explicitly in my /etc/fstab and then I have some null mounts and the null mounts are empty

hi all

Hi

hi

The blender version for freebsd 14 (3.6.1) has a segfault bug in a feature I need. How do I go about handling this?

ideally I'd upgrade to 4.1 but something tells me that's not going to be easy

i am working on getting a zfs dataset to show in a jail and the jail is able to "see" the datasets with a zfs list but when i do try ot mount it, i get this error message: cannot set property for 'storage/movies': 'mountpoint' cannot be set while dataset 'zoned' property is set

afternoon

entikan: bugs.freebsd.org/bugzilla/show_bug.cgi?id=275819 no idea what is missing there

Title: 275819 – graphics/blender update to v4.0.2

are we affected by the xz backdoor or whatever?

Only Linux is

mmlj4: it targets linux distros which have sshd which loads systemd library, which loads xz, which rewrites it's functions

ah, thanks

ketas: that's one known possible target. so far nobody knows the true target, there are a lot of programs which use RSA and link to liblzma

that payload seems have some argv[0] = /usr/sbin/sshd check, so pretty sure only some sshds where directly affected, but as it was a RCE, no idea what happend after that

there is some discussion on the mailing list about other issues in the source which don't seem directly related to the sshd code, but it's not clear if that's another vulnerability or just preparation for something that would have been added later

That malicious agent was playing "the long game". We will be learning much as it is studied and reverse engineered.

systemd :)

OT here but the main issue around the xz exploit was that systemd brings in a godzillian million lines of dependent code that is not needed nor otherwise used. That's definitely on systemd as a problem.

rwp: i don't think this is systemd's fault. Linux vendors could have chosen to implement the systemd notify protocol themselves (it's extremely simple) but made the decision to link to a systemd library instead

lw, Yes but the implementation is strongly influenced by the mentality that systemd must be obeyed and must be used for everything. It's not technology at this point. It is a cult with religious zealots.

i don't know what that means - there's no requirement to "obey systemd", you can implement the (publicly-documented) notification protocol any way you like, as far as i know

linking to a systemd library in sshd certainly doesn't seem like a great idea (at least in hindsight) but systemd doesn't force anyone to do that

rwp: if the vector via systemd and xz didn't exist, they would have found another way to bring the payload into sshd

nimaje: or just exploited it via the linux kernel, since xz is imported there

i assume they decided sshd route was less likely to be detected

lw, If you participate in any interaction with any of the distros that use systemd and propose even accidental ability to do something without systemd you will be shouted down as a bad person for not using systemd. It's a peer pressure thing. You might not find it in the systemd documentation. But you will find it in any interaction with the people.

rwp: this is not about whether sshd supports systemd or not. they could have provided this systemd-related functionality without linking to libsystemd, which would not have brought in liblzma/xz

the notification protocol is *extremely* simple and trivial to implement in an application

OpenSSH upstream does not use it at all. It was the systemd developer base that imposed itself upon sshd. Do you think systemd developers are going to use something systemd independent?

rwp: i'm not suggesting they use something "systemd independent" - what i'm saying is that this systemd functionality can be implemented *in exactly the same way* to talk to systemd without linking to libsystemd. that doesn't make it more portable and it doesn't change what it does - it simply implements exactly the same functionality without bringing in libsystemd's dependencies

given what we know about exploitation methods for network servers, even before this issue, not linking to libsystemd in sshd would have been a fairly reasonable choice

Uhm... It's certainly possible to do anything. What I am saying is that they won't do just anything. They will force implementation using systemd. That's just what they are doing. Everyday. And if anyone proposes something different then they will have to fight tooth and nail to get independence instead of systemd. That's just the facts of my experience dealing with them.

what do you mean by "force implementation using systemd"?

the feature we're talking about is to allow sshd to communicate its current state to systemd over the notify socket - however you implement it, it's specific to systemd, so this isn't about doing something "with systemd" or "without systemd"

I'll put on my Devil's advocate cap here. This is not me. Since systemd implements this functionality already then you should be using systemd to do it. Not using systemd is always going to be the wrong thing to do.

do you mean libsystemd, rather than systemd? because systemd is always involved here, the only question is whether to use libsystemd or not

It's Debian Policy as decided by the ctte to use systemd as the default infrastructure for Debian. By Policy we do not need to support any other solution. If you want to do something without systemd then you should fork the package and maintain it yourself.

It is clear that you are not using Debian. Since by Policy Debian is using systemd. Please say what OS you are actually using?

I have had all of the above said to me over the years.

...

rwp: i think the argument lw is making is that you don't need to *link* to libsystemd which has in-process memory access and depends on liblzma. however i do agree that a systemd discussion here is a bit irrelevant

dstolfa: yes, exactly

And in the end they are right. I am here in FreeBSD using FreeBSD on my servers and on my desktop now. So in the end the are now proven correct.

Discussing systemd here is completely off topic.

there is no need to link to libsystemd to do what sshd does, and not linking to sshd does not mean you're "not using systemd" - that Debian policy quote is completely irrelevant

Unless FreeBSD decided to adopt it. And then it would be an awful day.

i'll drop it, but the original statement i was replying to (about systemd) seems incorrect, so i wanted to correct wrong information

It's relevant because you were asking and perhaps insisting strongly that systemd folks were not requiring use of systemd everywhere. That's the point I was refuting.

no, i didn't say anything like that.

No one disagrees that it isn't technically possible not to use libsystemd there. Many don't. But Debian et al are linking it it. Because that is the systemd way to do things.

systemd is like that science. and if you question it...

You are questioning it? You must be a heretic!

Anything unrelated to elephants is irrelephant. Let's move on. Sorry I ranted so strongly. It's a sore point.

are you anti-systemd ?

its a joke :)

rwp: even Poetttering said, if all you're doing is sending a notify, use a fuckin socket() call. Don't link all of libsystemd if that's all you're doing.

My point that I've made a couple of times now still stands: If that pull request had been properly reviewed instead of ignored, people could've come to that conclusion, instead, distros just started pulling it as "good enough"

Hi everyone!

Does anyone know if we're going to see errata notices / OS patches released to address libarchive?

Title: tar: make error reporting more robust and use correct errno by emaste · Pull Request #2101 · libarchive/libarchive · GitHub

jmpp: i don't know, but i would suggest asking Ed since he submitted the PR

(emaste⊙fo)

already did in the GitHub PR

but just wanted to check the box of asking here, in case anyone knew the answer

does Ed hang around here in IRC?

jmpp: i am curious too so i asked him on Mastodon

will let you know if he replies...

i don't think he's on irc here

thank you, most appreciated!

what a shitshow this xz ordeal!

I am just flabbergasted reading the details, how it occurred over the years, everythign that went into place, the ramifications

jmpp: i really hope this leads to a serious evaluation of the human factors involved in open source development

other industries (like aviation) recognised this a long time ago, software engineering really has not

by far the most important resource, for sure

and surely one on the lower-end of of our attention and focus

lw: right, when it was realized that a pilot had the capacity to, oooppsss, fly a plane into a giant wall, whether that was a mountain... or a building?!

jmpp: i mentioned this in another channel (that perhaps we should consider the needs of individial open source developers) and someone did a big eye-roll about "coddling" people and "making their life perfect"... pretty clear we do not have a 'safety culture' in IT :-(

(i've thought for a long time that 'software engineering' is a bad term, because engineers normally have ethical and moral obligations in the things they do, and software 'engineers' do not have those)

lw: sounds to me like the kind of person who'd not even consider contributing to an open source project in any way, and then feel entitled to complain very loudly about bugs, delayed release schedules, etc.

lw: I'd tend to agree. Computers are, simply put, general purpose software machines, and people tend to not appreciate the ramifications of what those machines can do with the (in)correct set of instructions, and therefore tend to not think about that problem too much, as opposed to how a civil engineer, for example, would think about what'd happen to a bridge if not built correctly

a fuck, just realized macOS has xz 5.6.1!

at least, as far as we know, macOS isn't affected by the backdoor

right, right, Linux only

and it's not bundled by Apple, it's my MacPorts installation

In the there's-a-xkcd-for-everything dept: xkcd.com/2347 and explainxkcd.com/wiki/index.php/2347:_Dependency#Transcript

Title: xkcd: Dependency

port outdated --> xz 5.6.1_0 < 5.4.6_0 (epoch 0 < 1)

heh!

V_PauAmma_V: heh, i mentioned this specifically in my comment on the other channel -- everyone always linked this xkcd, no one does anything about it

cf. openssl

and IIRC, somethign similar happened with cURL at some point

i wonder, if i have both ipfw and pf enabled, which goes first? i'd like to use ipfw for NAT64, but pf for firewall, since ipfw is missing important feature like ipv6 fragment reassembly

apparently OpenBSD's pf supports nat64, maybe i should just use that

Title: Reusing code from zip size known and adjusting comments · libarchive/libarchive@02cfa8a · GitHub

facepalm!

V_PauAmma_V: is that a nod about using OpenBSD? i did, once, many years ago... maybe i should see how it's doing nowadays

(i always preferred NetBSD, but NetBSD's npf doesn't seem to do NAT64, and since pf's upstream is OpenBSD, i guess it makes sense to just use that...)

lw: Ed must be incredibly busy right now! libarchive/libarchive #2103

Title: re-review commits · Issue #2103 · libarchive/libarchive · GitHub

2103 – syslogd cannot log to ttys bugs.freebsd.org/bugzilla/show_bug.cgi?id=2103

jmpp: i have the impression he's always quite busy

i really wish there one OS that did everything i need and wasn't Linux

other than my Unifi devices, I don't have any Linux at home, and I just couldn't be happier!

i've been having endless problems with 15.0 on rpi to the point that i'm considering booting Linux on them and running FreeBSD in a VM...

and I do, of course, know that this situation right now is not per se Linux's fault, but man, I'd hate to be right now in a position of having to defend the Linux echosystem (*cough*TrueNAS SCALE*cough*!)

that a lot of talk there was here

personally i'm happy if other people use Linux, that just means fewer exploits targetting FreeBSD or other OSs

since my highlight

why imagemagick is pictured as small stick in that xkcd

it's open?

so you can't really kick it off

causing contraption to collapse

how do i enable the audio jack port on freebsd?

has anyone tried "Chimera Linux"? chimera-linux.org/about -- it seems to be a Linux kernel with FreeBSD userland...

Title: Chimera Linux - About

lw: re engineers having obligations, phk has written about that at some lengths, with the go-to example being electricians who're certified, or at least work under someone whose job it is to check that anything does matches the certification specifications they hold

it's interesting that we have code of absolutely equal criticality to electrical engineering, but without any of the certification requirements

as for macOS, the presumptive apt did clone ziparchive, which is used in macOS: github.com/JiaT75/ZipArchive

Title: GitHub - JiaT75/ZipArchive: ZipArchive is a simple utility class for zipping and unzipping files on iOS, macOS and tvOS.

debdrup: yeah, most engineers have obligations... but software 'engineers' really don't, from what i can see

i suspect if phk doesn't know about them, nobody does :)

he probably wouldn't know without checking either, but i'm certain he knows how to check

i know in some fields, like aviation, there are specific engineering criteria for software and you could probably call that 'engineering'

but that ofc really doesn't apply to open source

it doesn't apply to proprietary software at large either, it's specifically fields with much larger oversight

yeah. i just mean it doesn't apply to open source since that's specifically what matters to us

(ofc, Boeing showed us that even having these criteria doesn't guarantee funcitonal software... but still)