Liblzma Welcome Package?

Hi there,

Do you guys have a welcome package for the liblzma disaster. For users who can no longer trust systemd and packages maintainer?
 
On FreeBSD, just use xz/lzma from base or ports as usual. My understanding is current information about the exploit shows a variety of conditions that were not met or present/available on FreeBSD. Release versions were not including those versions. FreeBSD doesn't have systemd. "Packages maintainer" may be interpreted as the maintainer of a port or who brings the code into base; did you mean the original project maintainers? I wouldn't expect a special welcome message or something for people looking to migrate. grahamperrin has collected a number of references about this topic so I'd recommend finding the thread with that if you need some valuable reading on the topic.
 
FreeBSD has its own issues and disasters, just like anything else.

Patch often, have test systems, keep an eye on the security news, have lots of backups, keep your systems up-to-date.

The chap behind liblzma got a change through that's just been patched and coming through FreeBSD ports:


It's been there since 2021:


Sadly, nothing is perfect, so you may be trading one set of issues for another.
 
To be even more fair, systemd was never involved in any other role as that of a proxy. Only when you build the OpenSSH version with systemd support, the openssh will also link against the lib with the payload. This is a proxy event.

One solution would be to have a demand that all system daemons which open a port to the network to NOT be dynamically linked. That way, the developer/maintainer of that thing would have a chance to audit the result, and I have a feeling that the *ssh guys will want to have a quiet word with the bad actor in this drama. At night. I know I would.
 
Only when you build the OpenSSH version with systemd support, the openssh will also link against the lib with the payload.
To be yet more fair, there was no systemd support in OpenSSH until VERY recently (12 hours ago):

Seems they came to the conclusion that distributors strongly want systemd integration, so they came up with a solution that does NOT involve linking any (pontentially unaudited) libraries.
 
Can I be a fly on Theo's wall for a minute? He will surely be "opinionated" about this.
Good on them for not wanting to put in all and the kitchen sink. But what would it really be good for?
 
I have a feeling that the *ssh guys will want to have a quiet word with the bad actor in this drama. At night. I know I would.
Theo is Canadian if I recall correctly. Canada, Ice hockey, Warren Zevon Ice Hockey song. Good stuff.
 
Good on them for not wanting to put in all and the kitchen sink. But what would it really be good for?
systemd zealots stopping to complain about the "deprecated" forking mechanism (which is used by any sane init/rc system, so the first process can inform about success/failure to start simply via its exit code), which then leads to distributors adding their own "systemd support" patches, which DO pull in the kitchen sink and more. Actually a security measure, this commit will stop that kind of madness.
 
I do fear that this is only the tip of the iceberg, with maybe exploits spread out over different packages which only get active when you pull in two or three or four different libraries, maybe indirectly, into the right binary image.
 
To be yet more fair, there was no systemd support in OpenSSH until VERY recently (12 hours ago):

Seems they came to the conclusion that distributors strongly want systemd integration, so they came up with a solution that does NOT involve linking any (pontentially unaudited) libraries.
To be fair, this was done on openssh-portable. XD
 
I do fear that this is only the tip of the iceberg, with maybe exploits spread out over different packages which only get active when you pull in two or three or four different libraries, maybe indirectly, into the right binary image

I totally agree with you. I guess it comes down to does FreeBSD have a lower attack vector than other os.

Does FreeBSD differs in terms of way it gets new/update on software.
 
I do fear that this is only the tip of the iceberg, ...
Given the amount of work put into the current hack, it pretty much must have been nation-state hacking agency. The person named "Jia Tin" was probably a small group (probably 3-4 people) since the productivity seems very high for a single person. Those black-hat agencies with competent engineers exist in many countries, most prominently Russia, China, North Korea, Iran, and Israel. They are known to be large groups, with hundreds of people each. So we can expect that there are many more things like this.
 
I guess it comes down to does FreeBSD have a lower attack vector than other os.
It doesn't, but this isn't a one-dimensional thing ... it certainly has a different one. And it's less "attractive" for such attacks because of deployment numbers...

Does FreeBSD differs in terms of way it gets new/update on software.
For the base system, certainly. Third party software used there is tightly integrated (which among other things also means integration into the single BSD-make build system). This would already have rendered that specific attack disfunctional, the backdoor stuff was pulled in leveraging the GNU-autotools build system. It doesn't mean backdoors coming from third party upstreams were entirely impossible, but you certainly can't use some upstream build system for that and hiding will certainly be harder as well, as some code will certainly be read for integration with FreeBSD base.

For ports: No, not in general. Every package building system for some distribution of opensource software works differently, but they all at some point fetch source from upstream projects, compile and package that. Thinking about auditing all this upstream code is completely unrealistic. There are differences in details of course. Some package build systems declare it "best practice" to always obtain upstream code directly from source (mostly git) repositories. Again, this would have prevented this specific attack (the hook into the build system was in some GNU autotools generated file that's of course not present in the repo), but then, you can come up with other ideas as well. I've already seen discussions claiming one should never build packages from upstream-provided source tarballs. I think that's pretty much nonsense, if you can't trust the distfiles provided by some upstream project, how can you trust other stuff in their repo... In FreeBSD ports, the opposite is best practice: Always use upstream distfiles when they exist and are usable, only fall back to obtaining code from source repositories when you have to. This is just more efficient (often preventing huge build dependencies) and also more robust (you have an actual file with some initially generated sha265 hash, if THAT ever changes you know you have to take a VERY close look at the diffs).

In the end, all software distributions (like FreeBSD ports) can do is distribute software. If you can't trust upstream projects, you'll have a problem.
 
Back
Top