Systemd 241 Being Prepared With "System Down" Security Fixes

[filbranden]

phoronix

While fixes for the CVEs are indeed being pushed, I don't think a release v241 is coming out anytime soon, in particular not one that will only fix those CVEs...

I think you're reading too much into PR #11387 which says "Prepare release v241" and adds a section titled "CHANGES WITH 241 in spe" to the NEWS file...

This tends to happen every beginning of the cycle and not really close to a new release. For instance, the corresponding change for v240 happened in commit fcb975129693 back in July 2018.

Meanwhile, you'll see that the fixes are being pushed to the systemd-stable repository, which has branches for most of the recent releases. For example, I just pushed a backport of the fix to CVE-2018-16866 to v239 in stable last week. These branches are more relevant to Linux distributions, since they're most likely tracking specific versions of systemd and wouldn't really upgrade to v241 once one was released... Even ArchLinux tracks the last released version of it, so using v240 stable they'll get all the fixes they need. Fedora/RHEL/Debian/Ubuntu all track the branches in the -stable repository AFAIR.

So, yes, fixes are coming. But I don't think a v241 is going to be released anytime soon. Particularly not just to address these fixes.

Cheers and thanks for the coverage of these systemd vulnerabilities!

[cybertraveler]

Maybe it's my own bias here, but it seems to me that people take a certain amount of delight in bugs in systemd. That seemed evident to me when I read about these vulnerabilities on Reddit.

To me it's simply a case of 'bug found in systemd...systemd devs patch it and release a new version'. This is pretty much the case with every software project ever. People talk about systemd like it's the only program to ever have an exploit found in it.

I can't speak for others, but I personally have extra concern for systemd, because the project goal is to become ubiquitous on GNU/Linux systems. It's already become very commonly installed despite not always being necessary or desired. For example: Canonical shifted from a Sys V init style init system to using Upstart (in house developed) some time around Ubuntu 12.04 LTS. Upstart worked beautifully and Mark Shuttleworth (the Canonical founder and CEO at the time) had no interest in Systemd for Ubuntu. Only after (quite controversially) Debian picked up Systemd, Canonical then took the path of least resistance and also adopted Systemd for Ubuntu (Ubuntu is derived from Debian).

I consider the pros and cons of Systemd to be secondary to the above point. I actually like Systemd (I also like Upstart & Sys V style init systems). What I want to see preserved, is convenient, freedom of choice and a diverse software ecosystem. If that is the case then serious vulnerabilities in Systemd (like the above) are less of a problem. They affect less people. It also makes Systemd less of a target for the dark forces in our world who just love centralized things. If I were them, I'd love for Systemd to become even more popular than it is now, so when I implant a vulnerability in it, I can target many systems all at once.

Before anyone mentions it: yes, I also consider the Linux kernel's popularity to be undesirable. I love Linux, but I'd like to see more kernels. I'd love it if one day it was common to see people using GNU/Hurd and GNU/kFreeBSD. I'd also love it if the *BSD systems got more popular. I love the fact that clang is very successfully competing with GCC now.

[Britoid]

there is a minor number of people which are not capable to learn something new and got triggered when they read systemd and write loud comments how bad it is while the majority is just using it or don't care at all about what is running as PID1

wasn't the bugs in journald, which doesn't run as PID1.

[cybertraveler]

Could it just be that systemd's code is a mess that relies on

alloca()

, a security nightmare? Of course it makes it easier to write C, but the cost for that is way too high. It should be forgotten and never used again, just like VLAs. I'd say that if they put in the necessary effort to remove all uses of it from the code base, they'd make it much more secure (especially because they'd be able to notice plenty of mistakes around these parts of the code base as they're rewriting it).

There are definite risks to using alloca() and other things to consider (e.g. it is not in an ISO or ANSI C standard), but I personally don't think there is anything intrinsically wrong with using it. I think the most important thing is that C programmers know exactly what alloca() is and what the dangers are.

Is alloca() generally more dangerous than malloc()? Arguably yes.

Is a motorcycle generally more dangerous than a car? Arguably yes.

Should you never use a motorcycle or alloca()? IMO, no. Just be aware of the dangers, exercise additional caution when using them and share your wisdom about these things with your fellow man.

[SystemCrasher]

I suppose so if you use bounds checked arrays.

The main reason why C does allow out of bounds access is that storing the array length was horribly expensive when computers had only 1 to 32 kB of RAM. Now they have 32 GB, but C programmers will still argue that billion dollar bugs every now and then are way better than wasting 4 bytes worth of space for every array.

These days there're plenty of use cases where few extra bytes here and there turn into gigabytes when put at scale. And plenty of systems lacking gigabytes - those nuts inclined on their just stupid overgrown i9 PC are annoying and blind, to my taste.

Also, bounds checks are not free in terms of CPU cycles either. So it slows things down - and some code is performance critical. I guess it is a case for something like system logger, should it get slow, it like a big trouble on the way. So idea to check bounds isn't really bad on its own, however idea to force everyone doing so... leads us to "high-performance" monsters like .NET and Java once implemented at full swing. Nope, thanks.

[SystemCrasher]

most of my systemd-units are secured in a way hat even root exploits in most services would be little of use or at least restricted that copy&paste exploits fail quickly

Most of systemd's own units also secured considerably - so they only able to do what they are meant to. Good idea any day.

[caligula]

Sure my idea was bad but no, definitely not a bait. I'm actually interested on how this can be accomplished in C. I know it is easy with an Array class in object oriented languages.

1) You can have a boxed type which contains [length, pointer].
2) Or, you can store the length in the beginning of the array using a standardized length for this field.
2b) If you also want to be compatible with legacy null terminator using C routines, you can always allocate +1 and use a NULL terminator. In addition you might pass around the pointer to the start of the payload so that the length field is allocated starting from a negative index.
I've seen all of these in real world compilers/systems.

[SystemCrasher]

yes, sadly journald lacks some of the typical hardening but that's a differnt thing than all the systemd-haters pretend

Humm it seems sandboxing also got at least partially aplied to journald. However, capability set it uses seem to be kinda excessive for logging facility - and I would admit it kinda BUG. Why the hell logger facility may want something like CAP_SYS_ADMIN at all? Seems like if it subject for systemd bug or so.

they never realize that the amount of hardening systemd provides with a predictable and useable configuration provides, even for foreign units by just write a small dropin whould never be possible with a initscript at all

I do use systemd sandboxing - and wouldn't dare to sequence all that using external utils and shell cruft. Say, filesystem could be already unavailable at point I want to call something to switch user or drop privs, etc - and it nearly impossible to sequence this way. Ironically, journald seems to have issue using facilities of systemd in efficient way... kinda omission to my taste.

[jabl]

You don't need to perform checks every time you access the array elements. Instead, only once per operation, which means O(1) overhead per any array operation. This is already way better than the current behavior. Computing the length would be O(1) instead of O(n). A boxed representation only requires few bytes. If you care about the caches so much, use a custom allocator.

For Rust, in the usual case of a "for element in collection {...}" style loop, the compiler can omit the bounds check entirely (since it's the compiler that is generating the code to do the index/pointer manipulation, not the programmer).

[pal666]

Would Rust have prevented this?

sure, no code written means no vulnerabilities