Slashdot Mirror
Multiple Linux Distributions Affected By Crippling Bug In Systemd (agwa.name)
An anonymous reader writes: System administrator Andrew Ayer has discovered a potentially critical bug in systemd which can bring a vulnerable Linux server to its knees with one command. "After running this command, PID 1 is hung in the pause system call. You can no longer start and stop daemons. inetd-style services no longer accept connections. You cannot cleanly reboot the system." According to the bug report, Debian, Ubuntu, and CentOS are among the distros susceptible to various levels of resource exhaustion. The bug, which has existed for more than two years, does not require root access to exploit.
and been around for 2 years and doesn't require root access??
If this happened on Windows, I & many others would be scornful of it.
Pain is merely failure leaving the body
Putting this level of complexity at such a low level of the system is going to cause show stopping bugs. And, with every new release, more complexity is added.
This is not a bug, it's a feature. This is the systemd way and you've all being doing it wrong!
Regards,
The Systemd Developers
Fortunately, we have so many different Linux distributions that this is not a problem! (...right?)
Ezekiel 23:20
All the people that were telling you that this init system called Systemd was overly complex, unaudited and insecure had warned you that this was coming. All the "Troll -1" modding on people that posted such warning here did not prevent the inevitable.
Not convinced? Here's a graph of the number of issues opened/closed since systemd moved to github last year.
Anons need not reply. Questions end with a question mark.
How long are systemd proponents going to evade accountability to crying about detractors, greybeards and positoning opponents as anti-change.
Any criticism of Systemd and out come a hoarde of Redhat supporters and astroturfers to change the focus swiftly from the technical to the political
That is far from a detailed description and more of a list of uninformed rants. Much better to read the informed reply to TFA here: https://medium.com/@davidtstra...
What does feel surreal is that people now all of a sudden pretend that SysV init where without exploits while going completely berserk when systemd have a non remote exploitable denial of service bug that cannot be used to take over the machine that also where patched three days ago...
https://medium.com/@davidtstrauss/how-to-throw-a-tantrum-in-one-blog-post-c2ccaa58661d
Can't have anyone criticizing any aspect of the holy systemd.
Whole thing boils down to:
"Following security practices in an init system is hard, and you've never done it so leave us alone."
Completely ignoring the fact that the only reason they patched this thing is because he made a big deal out of it.
And on what planet is testing for corner cases like empty strings the domain of fuzz tools?
That seems like a pretty standard test case to me.
I can understand if you don't test for a 1MB string, but empty seems like a no brainer.
If you're dissatisfied with systemd and you don't need any of its fancier capabilities (which as an end user I'm assuming would be Docker stuff), please consider switching to a non-systemd distro as soon as possible and (if you can afford the time or money) contributing to their development. The more support systemd alternatives can garner, the more likely it is that projects to will resist unnecessary systemd dependencies and it might even be that systemd itself will eventually become more modular and moddable.
I'm not a hater. I cringe every time I see +5 comments claiming that systemd didn't fix anything. Declarative syntax is (at least in principle) a massive win, especially for distro builders. And LXC is amazing stuff, and I certainly cannot fault Red Hat for wanting containers to behave perfectly. Unless something like Genode scores a major coup, containers are definitely the future of secure and robust computing.
But the actual details of systemd's course have been hair-raising. It needs to be more UNIX-like and less draconian in its requirements and less toxic in its effects on the FOSS ecosystem and unfortunately (given Red Hat's behavior over the past decade) it appears that pushing alternatives hard is the only way they can conceivably be convinced to change their ways or reform anything moving forward.
I encourage all of the haters here to try and put your money where your mouth is. Install, use, support and help promote a distro like Devuan or even better: go and find one of the multiple OpenRC distros available. OpenRC can't be the all-in-one automagic solution systemd endeavors to be, but it doesn't hide tons of stuff in huge C binaries and it's addressed most of the common frustrations people have with SysV. Arch Linux has an OpenRC variant (the standard install uses systemd), Gentoo was the distro that started OpenRC years ago, and Alpine linux uses it (which isn't an ideal easy desktop distro, but it's amazing for those wanting a secure minimal distro to build on and last time I checked it does run XFCE and Firefox.) There are probably others.
No its a technical struggle.
The UNIX philosofy is to make many smaller programs that does one thing and does it well. From a bug point of view that been godsend; smaller programs are easier to debug and test.
Large complex programs will always be a problem. Like webb browsers and systemd. The more complex a program becomes and the more it does the more complex is it to write secure code for all situations.
Just saying it like it are.
Try to explain to foreigners that cleave means to stick tight to or to split apart from, or that sanction is to permit or to forbid something, and they will run screaming.
"Debian, Ubuntu, and CentOS are among the distros susceptible to various levels of resource exhaustion."
Whew! Thank goodness I run Red Hat!
#DeleteChrome
That is far from a detailed description and more of a list of uninformed rants. Much better to read the informed reply to TFA here: https://medium.com/@davidtstra...
More clueless autonomic defensiveness without any reflection on what the impact of the bug actually is. I especially enjoyed this old chestnut as the author attempts to fisk the original bug report:
"SystemD, let me just stop you there. I know the Linux kernel. I've worked with the Linux kernel. You're no Linux kernel."
The incredible hubris of asserting parity with the core of the entire OS, the ignorance that underlies the statement that init was written in C and runs as root, so it's every bit as vulnerable... How the fuck do you even make code run? Do you even teh logic?
The SystemD team is the Microsoft of a new generation. Doubling down on their mistakes; shouting louder when they don't get their way; using every available ratiocination and intellectual contortion to excuse themselves; resorting to any means to make their strategy win, instead of stopping to ask themselves for once, 'Are we following a winning strategy here?'
Thank g*d I quit writing software last year. Dealing with Microsoft's mind-crushing blindness was enough for one lifetime. Now I can just grump about it and walk away.
Crumb's Corollary: Never bring a knife to a bun fight.
In the meantime you may avoid using systemd as init in Debian by installing sysvinit-core or in Ubuntu by installing upstart-sysv in your transition to a systemd-less distro such as Devuan.
If you are using Debian Jessie, you can switch to Devuan by simply changing repositories. Its still in beta so don't do it on production servers yet. But do plan your migration, before this gets out of hand.
Artix
Your Linux, your init.
It's another straw on a very overloaded camel's back - so this "small bug" just gets added to the list.
I've still got pretty well everything on linux still on RHEL6/CentOS6 because the vendors of an application used in the place don't trust systemd yet. The few workstations I have on something newer are as unstable as MS Windows machines used to be - one wouldn't even boot when systemd hung on a wireless mouse dongle - so much for parallel init! It should have failed then moved on instead of blocking every single time it hits that USB device, and the rumoured parallel init should have enabled it to be doing other stuff instead of completely blocking. That's just one, every few weeks there's some different fuckup of the sort we used to laugh at MS Windows.
I've got 3 separate servers that all run different OSes. 1 in-house with direct control running Gentoo with OpenRC. Then there's the two VPS's. One is running CentOs 6.7 with Upstart. Then there's the PoS VPS I have free on Microsoft Azure running Ubuntu something-or-other with SystemD. Nothing critical is on this server...it just serves as a lab environment and data passthrough. The only time I've ever run SystemD on a system I own with physical access was on my primary desktop...which is never permanently online to begin with.
There have been too many points with a systemd system that I don't trust. Nothing to date with the system has personally affected me to say it's as worthless as I think. I just never trusted it because it just felt too much like a Windows Registry clone in how it worked, which in itself screams that it cannot be trusted. This bug seems to prove my intuition correct.
SystemD a black box that have a lot of features that's hard to understand unless you dig through the source code trying to trace down why it doesn't do what you want and why it doesn't tell you anything about what's wrong.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
when grey-haired conservative fuddy duddies warn of something, you should PAY ATTENTION even if you disagree.
In this case, the "conservative" is certainly not in the political sense, it's in the technical sense. The core philosophy of UNIX was: small dedicated programs doing discrete things (which can be easily developerd, debugged, tested, and yes... replaced/substituted. Many warned that systemd was the polar opposite and would inevitably invite this very sort of issue. The warnings were ignored because they were not consistent with what the cool kids wanted. It was much more cool to create a whole new gluttonous monster, than to do the hard work to fix a bunch of long-standing and not glamorous basic usability issues that might actually help Linux take over the desktop.
In the political sense a similar thing happened with Obamcare, where conservatives kept pointing out that the basic plan did not pass the economic "smell test", and that inevitably the rates would rise and the markets would fall apart because of the poor planning.
In both cases, the hard-charging progressives (in the technical sense for the former and the political sense for the latter) ranted and raved against the cautious conservatives flinging insults about being backwards, stuck in the mud, opposed to progress, etc rather than facing the actual criticisms, considering that thier opponents might have serious and valid concerns, and then addressing those concerns. In both cases, when the inevitable "I told you so" comments arise, the advocates of the changes get angry and complain and propose moving even further in their chose direction, without facing that the now proven problems are real and were real - they want to solve a real problem with politics and name calling.
Incidentally, before some partisan hack rates this "Troll", I'll point out that this is a trait of human nature and applies to the political right and technical conservatives as well. Some right-leaning "fiscal" conservatives love to propose reductions in social spending while ignoring left wingers who suggest some might be harmed, instead of facing the problems suggested. Some technical conservatives, particularly in places like the FAA, can actually suppress the increase in safety that modern systems could provide out of excessive fear of the risk of "new" (AOA indicators on small aircraft, and the typecerts required to put new avionics into older small aircraft come to mind)
I've made several requests for systemd proponents to supply a use case that SysV initd could not support and haven't received a satisfactory reply to this purely technical question. I was interested in what systemd could offer over initd. I find systemd proponents are overly veherment in their criticisms of initd proponents.
I sense this comes from an inability to address the issues raised and, perhaps a mindset that anyone who has an appreciation for initd's elegant power will simply be bulldozed into irrelevance. I think systemd's criticism of the rc scripts that starts a linux based system is valid criticism however we have to keep in mind that they were devised by Red Hat. It is dealing with rc shell scripts that are the brunt of the justification for systemd.
In that sense the unitd solution is tidy but also reveals the justification to replace initd is not based on a full understanding of its capabilities, or even an understanding of was it is, a process manager. rc scripts are only meant to prepare the system for entries in /etc/inittab, yet everyone tries to get everything done in rc, which serializes the Linux boot process. A parallell boot is completely achievable by using initd properly. I know there is more to it, like events and messaging, I'm just citing one example.
Yet I've never seen a Linux distro that's utilized initd's /etc/inittab file properly. Especially a Red Hat system. They don't use initd properly, the rc scripts are bloated with rewrites of what initd already does, and now we're replacing initd, keh? initd has yet to be utilized fully on modern linux systems.
Criticisms of sco the company aside: sco *as a distribution of unix* had an interesting adjunct feature to initd, the 'enable' and 'disable' command that managed entries in /etc/inittab, where you would configure the characteristics of the system you were running. Franky I think this is functionality is essentially
I think initd would make a lot more sense to more people if this functionality had been available in Linux from the beginning. It is true that initd is beguiling in terms of it's simplicity wrt its power, but it is also very worthwhile. It is supposed to be small as that is where the skill is expressed.
initd is where you design the characteristics of the system, it is not an event manager and all the other things systemd is supposed to be. Something that does all the functionality systemd has, belongs as an inittab enty, not as the first process the kernel runs.
The point of a bug like this is not that it is a big deal itself, the big deal is the failure mode systemd has been revealed to have due to its complexity. This the type of concern I have about systemd, what else can trigger such a failure mode. I have seen initd in a variety of failure modes and not once has it ever consumed all system resources and disconnected running processes.
Now we've seen systemd do something that initd can't.
My ism, it's full of beliefs.
The whole "FreeDesktop" Movement seems to be about making Linux more and more incomprehensible.
My theory for why this is is like this:
There are lots of people now growing up when Windows kinda worked (since about 2000). At the same time, involvement in "Open Source" software is seen as a good career move. So they churn out some shitty badly designed code as potential recruiters cannot tell good from bad code. Also they take part in design processes without the experience necessary for this. The result are overcomplex buggy solutions which suck in manpower to maintain them.
Take a look at the *BSD people. The team maintaining OpenBSD is probably smaller than the SystemD team, yet they manage to maintain a whole operating system.
The core C code of sysvinit was feature-complete, reviewed, debugged and tested years and years ago. Its original design goals were satisfied, and the project is "done". Software does not need continual churn to mark it as "maintained". The same applies to startpar/insserv and other ancillary bits. If you found a bug in sysvinit, I'd review and test it, and push a commit for it. I no longer maintain the Debian packaging, but I still have upstream commit rights should I need them.
Compare this with systemd. It doesn't have the same clearly-defined scope; it's not possible to say when it will be complete as a result. Software can be complete and finished.
My guess* is that they are from separate stems. In Dutch, kleven (clay-vun) is to stick together, and klieven (clee-vun) is to split apart.
No idea where the contradictory meaning in sanction comes from, in Dutch 'sanctioneren' (v) also has both meanings and people get confused.
*) And Internet confirms it :) http://www.etymonline.com/inde...
I've always loved the multiple meanings in "the boat is fast". Just like the word "secure", it can mean wildly different things:
If you give the command "SECURE THE BUILDING", here is what the different services would do:
The NAVY would turn out the lights and lock the doors.
The ARMY would surround the building with defensive fortifications, tanks and concertina wire.
The MARINE CORPS would assault the building, using overlapping fields of fire from all appropriate points on the perimeter.
The AIR FORCE would take out a three-year lease with an option to buy the property.
Just cruising through this digital world at 33 1/3 rpm...