Slashdot Mirror
Linux systemd Affected by Memory Corruption Vulnerabilities, No Patches Yet (bleepingcomputer.com)
Major Linux distributions are vulnerable to three bugs in systemd, a Linux initialization system and service manager in widespread use, California-based security company Qualys said late yesterday. From a report: The bugs exist in 'journald' service, tasked with collecting and storing log data, and they can be exploited to obtain root privileges on the target machine or to leak information. No patches exist at the moment. Discovered by researchers at Qualys, the flaws are two memory corruption vulnerabilities (stack buffer overflow - CVE-2018-16864, and allocation of memory without limits - CVE-2018-16865) and one out-of-bounds error (CVE-2018-16866). They were able to obtain local root shell on both x86 and x64 machines by exploiting CVE-2018-16865 and CVE-2018-16866. The exploit worked faster on the x86 platform, achieving its purpose in ten minutes; on x64, though, the exploit took 70 minutes to complete. Qualys is planning on publishing the proof-of-concept exploit code in the near future, but they did provide details on how they were able to take advantage of the flaws.
Giant bloated executable where trim purpose built utilities and text should be used.
Looking at the code, all three of these bugs are inexcusable. The systemd devs really are incompetent.
In case you're interested to know the breakdown...
Politics; n. : A religion whereby man is god.
for me... I switched to Devuan a few months ago.
Yes, I know there are plenty of bugs and vulnerabilities to go around, but based on the frustrations that systemd caused me, I think I am afforded a bit of schadenfreude.
My beliefs do not require that you agree with them.
new things are great! alternatives are wonderful! systemd is just awful.
There is some truth to this. Linux is just a kernel, but there are myriad userland programs, toolchains, and other ancillary software bits that make up a GNU/Linux system. Linux (full system/any distro) is so balkanized. Companies like Red Hat employ the programmers who write stuff like systemd/pulseaudio, etc., so they automatically steer the direction every other distro must go in. I was shocked when Debian adopted systemd, and now more and more software has to have it as a REQUIREMENT. This is one reason I like KDE. I've been using it as a desktop since 1998. I use Kate and Konsole all of the time, and my workflow revolves around them.
BSD, on the other hand, for all its own faults, is not "grown" like Linux, but engineered. It's a full OS in its own right and end users can install their own preferred userland and ancillary software. I'm really close to just adopting FreeBSD.
Shitty windows-ini-style Unit files, binary logs, 12 different subsystems gobbled up and "integrated" ... I mean did this kind of shit surprise someone? Really? After years of supporting Systemd and solving it's problems for others I can say with limited authority that, yes, it really is garbage. I know there were a few people who thought systemd was just "progress", but no it's a schism, a coup, a shitty revolution that left everyone worse than when they started. Linus and friends are too old and retarded now apparently to lose face and be critical of it because they stood by and shrugged while the Potterites and Fedora assholes ruined Linux. I mean BSD was always better, don't get me wrong. So, it's not as big a loss as some would frame it to be. However, it used to be fun, useful, and relatively untainted by anything this heinous but a few unenlightened windows folks came along and created this svchost.exe ripoff (systemd) for the purposes of enhancing GNOME and now you get this smelly mess that is now Linux. Ah well, it was (sorta) fun while it lasted. Back to my BSD boxes.
New isn't always equivalent to better, and my biggest objection to systemd is the fact that it's gone way past an init system. It has way too large a scope for what it was supposed to be and a core team that doesn't have the skill to keep up with that scope.
Mr. "My-printer-is-not-a-file" should probably go back to working on Pulse.
I don't know about that. These errors seem pretty basic if you look at the code. How did it even pass a LINT-style static check? Are they not doing any static code analysis? The entire codebase seems suspect based on these issues. There could be thousands of these in the code.
It's less about resisting change and more about resisting stupid.
The problem with systemd is that its design is wholly antithetical to the Unix philosophy. It is nothing less than a tragedy for Linux that something like it has become so tightly integrated into as many distros as it has.
File under 'M' for 'Manic ranting'
"niche operating system"
The 90's called and want this argument back.
Probably a good chunk.
That said, init and upstart solved problems in a fairly small domain: starting daemons in dependency order. SMF, launchd, and a few others did the same thing. They sucked to learn, but they gave us parallel startup, services that could start in response to events (logins, socket connects, etc.) and that was worth some relearning.
Things that systemd has embraced into its scope that SMD and launchd did not include:
Thanks to RedHat's backing, the systemd developers have a bully pulpit to force policy on Linux users everywhere. Like when nohup stopped working by default. The usual rationale from Poettering and company are that things are "broken" or "nobody needs that."
Right now, on my Debian box, in ~root/ is a script called thanks-systemd.sh. It mostly boils down to: cd /dev ; for i in dm-? ; do ln -s ../$i mapper/$(cat /sys/devices/virtual/block/${i}/dm/name); done
Because for about two weeks my system stopped autobooting due to some churn between LVM2 and systemd. LVM2's worked nigh-flawlessly for 20 years, and its semantics haven't changed.
It's one thing to change a clunky misfeature (init scripts) in some jarring way to make them better. It's quite another to take over most aspects of systems management, do them differently "just because," and break random things because of scope creep.
Pining for the days when The Glorious MEEPT!!! graced SlapDash with his wisdom.
Two of the bugs only possible in with unsafe referencing/allocation ... par for the course.
It's been at least a couple decades. Today, Linux is more widely used than literally anything else.
"Giant bloated executable..."
SystemD causes a lot of problems. That makes more money for people who work for companies that do Linux technology support.
Is that a giant conflict of interest? Was SystemD allowed by management of Red Hat because it would make more money?
Mark Shuttleworth said, "Losing graciously". (Feb. 14, 2014} "It will no doubt take time to achieve the stability and coverage that we enjoy today..."
Yet I can't help wondering how much of it is really just people who resist change because they don't want to learn something new. The init/upstart process was easy enough to understand but clinky and as full of problems as systemd really. Except, of course of the most common use cases where it had been worked out.
Gonna call citation needed on that, especially if you're combining them as "init/upstart".
upstart, when primarily running as a traditional SysV init (meaning handle initial setup procedureally, then execute an rc script which executes a series of rc#.d/ scripts, which is how upstart was used in RHEL6, for example, was neither "clinky" nor "as full of problems as systemd".
A primary reason so many people have problems with systemd is that it intermingles the complexity along its entire axis of execution instead of isolating it in a discrete manner. Any time you have event-based management you have the potential for intermittent problems, race condition security issues, memory bugs, etc.
In previous init systems, persistent management or event mechanisms hung *OFF* the init path and only affected their own children or the services under their control if something went wrong. (This goes for all service managers: inet, xinetd, supervise, whatever.) Meanwhile, the init path is controlled by one-time scripts and as minimal an event mechanism in PID1 as possible.
Now, all that complexity happens as PID1, or communicates back to PID1, or relies on IPC between the two that is not particularly tight and isolated. Waaaaay more potential for chaos results here, which is why these types of holes are more and more likely to occur.
Hire a Linux system administrator, systems engineer,
"The init/upstart process was easy enough to understand but clinky and as full of problems as systemd really."
No, it really wasn't. You are confusing user error with the actual utilities which were rock solid. There was some functionality missing but alternatives existed, they largely weren't widely adopted because that functionality just didn't offer enough benefit to be worth it.
The problem with systemd is that it was a solution that was built and broke all *nix design philosophy. Every layer of complexity added to a framework adds an order of magnitude of probability for error and trades flexibility for tight integration. If a bug does come up it will be fixed almost immediately with small and efficient utilities because you aren't debugging a complex behemoth you are debugging a tiny and simple application.
It really does just suck. It's not haters, it's not bias, it's not politics. It's also not only people resisting change, Systemd is just flat out technically inferior. Bad choices were made and the chickens definitely are coming home to roost. I get a *lot* of calls from frustrated/confused sysadmins who run into issue after issue with systemd. From subtle problems from malformed unit files to clear-as-mud dependency graph issues between units. Yes, they are fixable most of the time but systemd just throws obstacle after obstacle into your path. Want to know why something didn't work? Well, there's journald hording your logs as binary. Hope you have the magic decoder when your system crashes and journalctl pukes. I dug into systemd deeply because I support Linux and other systems professionally. I've studied a lot of the code to run down bugs or issues. I learned it quite well and it seems obvious that I know it's internals better than it's cheerleaders do. It shouldn't be this controversial. The only reason it is stems from the leadership folks not wanting to lose face and admit they made a serious mistake. Systemd sucks on it's own. It doesn't need fixing, it needs replacing. It's bad design that violates the "do one thing and do it well". It does a zillion things: all poorly.
https://www.qualys.com/2019/01... :
2018-11-26: Advisory sent to Red Hat Product Security (as recommended by
https://github.com/systemd/sys...).
2018-12-26: Advisory and patches sent to linux-distros@openwall.
2019-01-09: Coordinated Release Date (6:00 PM UTC).
Meanwhile, just two articles earlier on the same exact page you just posted to: "Windows 7 Users Who Installed January Update Report Network Issues; Some Say the Update Has Also Incorrectly Flagged Their OS License as 'Not Genuine'"
Slackware ships with a simple, effective BSD-style init populated by simple and readable shell scripts. Its BDFL, Patrick Volkerding, made the decision to purposely avoid systemd like the plague and I think he is right.
Install Slackware, and many sysadmin's worries will go away.
-- Look to the Rose that blows about us--"Lo, Laughing," she says, "into the World I blow..."
I haven't seen a systemd thread for quite some time around here I guess we're due.
Some of the rants and raves are actually pretty good.
Yet I can't help wondering how much of it is really just people who resist change because they don't want to learn something new. The init/upstart process was easy enough to understand but clinky and as full of problems as systemd really. Except, of course of the most common use cases where it had been worked out.
As for these bugs they don't seem to be making much of an industry problem.
How much of systemd is due to people who don't want to learn something old? It's always more fun to design from scratch than to actually understand the reason why it was done that way.
That is the more polite version of "you incompetent chumps make our searches easy and worthwhile. And we listened to a lot of System of a Dawn."
Let me go make some popcorn.
Personally, I refused systemd after learning it. So there's that too.
Knowledge is power; knowledge shared is power lost.
I heartily recommend Devuan.
Knowledge is power; knowledge shared is power lost.
Most people have either become resigned to systemd, or switched to something that doesn't use it. So one would expect the threads to decrease. I also haven't heard anyone say they liked it recently. (And I still don't. But I haven't switched yet because doing so would be a major inconvenience. But when I set up my next system, I probably will avoid systems that use systemd. So far I haven't seen *ANY* benefits, and I've experienced, and continue experiencing, many small irritations. I'm definitely considering devuan, but I'm even considering Unix. Unix would be a problem during transition, because my current partition formats are incompatible, so I'd have to set up an new series of backups in a format that both systems could handle for the intermediate period....so devuan has the inside track. Or Slackware. Or something that I haven't noticed yet. Or perhaps some version of Unix will become able to read/write ext4 partitions. Lots of possibilities, no real decision, but the fact that I haven't been saying bad things about systemd recently sure doesn't mean that I like it.
I think we've pushed this "anyone can grow up to be president" thing too far.
Even simpler than a systemd declaration is saying "Alexa, start Apache".
That doesn't mean that Alexa's AI code is simpler than a 20-line bash script. You're comparing the *input* to the systemd code, a config file, vs the actual code that does things in SysVinit.
In sys V, the shell script starts the daemon, it *is* the code. If anything is wrong or you want to change anything, you can look through the shell script and change things. In systemd, the declaration is handed to a binary that does who-knows-what.
I was a RedHat user back on v5.1. I tried to upgrade my system, and it was awfully painful. But I stuck with RedHat. Then I upgraded again. And again. Every time it got a little less painful, but it still sucked. Then I decided to try out another distro. Mandrake. It was nice, and I liked KDE! I upgraded a couple of times, and it wasn't too bad. So change was good. After a few more upgrades, it still wasn't that smooth. I decided to try out Ubuntu, and I really liked it. Since I was liking KDE I switched to Kubuntu. Change was good! I upgraded a couple of times - near flawless! Change was great! Then KDE started to really annoy me - too much flash, and eventually a bug cropped up that caused me all kinds of headaches. So I switched to Xubuntu. XFCE was great, and change was good! I upgraded that system several times, and it was very smooth. After 7 upgrades, things were getting less stable. Since i was going to reinstall anyway, i looked at other distros.... ah, Linux Mint. Polished, but with XFCE not overly so. I had found my distro, change was great! The method of upgrading was to reinstall cleanly, so I made sure to set up my new system so that was minimally painful. Then I was able to upgrade in place - painlessly! All was right.
Then after one upgrade, I noticed that my machine started having various issues. I couldn't shutdown cleanly. I would take minutes to shutdown, where it used to take seconds. I thought it was hardware at first, but it wasn't. It was systemd. I hadn't noticed before upgrading that they were switching to systemd. I had begun to trust Mint so much that I just thought it would be smooth. I learned more and more about systemd, and tried to fix the issue. No deal. So I gritted my teeth and dealt with it. Change can be bad. Eventually I got a different computer, and then I had complete confirmation that my issues weren't hardware related because they persisted. It was time to find a new distro.
It wasn't an easy search, because by this time systemd had kind of taken over. Mint only went to it because it's a downstream of Ubuntu. Clem (maintainer of Mint) confirmed this to me, that it wasn't his choice at all and it was just the easiest route to take.
I looked at the BSDs, Arch, Slack, and a few others. But because I was familiar with and really liked the apt package manager, I chose Devuan. It was not only a great distro, but I know that it is specifically focused on NOT implementing systemd. It was a simple install and upgrade, and my system is fast as ever and shuts down within seconds again. So again... change is great!
My beliefs do not require that you agree with them.
This is a legitimate question. Most people on slashdot seem to hate systemd. And most of you are programmers and work on Linux every day. Why don't you guys get together and create a new init system that blows systemd away? Isn't that what the whole spirit of FOSS is about?
...that broke the camel's back? FINALLY? PLEASE?????
Can the idiotic pro-systemd folks finally admit they were wrong, abandon the whole misguided concept, and start the process of moving back to unix philosophies and architecture? The world dropped xfree86 fast as a hat, pretty much spun on a dime and moved to X.org.... let that happen w/ systemd as well.
Or, better yet, just shift support en masse behind FreeBSD and get the hardware and desktop environment and app support back up there like it used to be. Honestly, that'd be the better path and the end result so much better.
Probably too much to hope for...
I come not to praise systemd, and certainly not to praise Poettering or RedHat...
But these anti-systemd rants would be more impressive if you guys had showed any signs of thinking through what you're saying about The Unix Way and all that jazz.
Yes, sometimes decentralized, small encapsulated components are a win, but sometimes monolithic designs where the pieces can talk to each other easily are a win-- You might notice that when Linus Torvalds was asked about this he made some rather mild comments about how some aspects of linux, like the graphic display environment has always been more monolithic.
Arguably, the initial reason perl was a big deal is it took a bunch of features from the shell programming world and stuck them all inside of one process-- you can do lash-ups of shell, awk, sed and so on, or you can just write a perl script and pretty frequently the perl script is really and truly a better option.
And take a look at some of the classic shell utilities some time. Look at the docs for things like "find", "tar", etc... do they really look to you like something that's designed to just do "one thing"?
You guys who keep intoning "the unix philosophy" over-and-over might want to stop and think about the way things really get done with unix.
But then, none of this is a defense of systemd, or the way systemd was put over...
someone has local access to your machine, you're doing it wrong anyway.
Linux is a multi-user operating system. It's designed explicitly to support multiple users concurrently with limited privileges.
Yep. I run it and love it on my Linux systems at home. At work, though, I have to deal with systemd all day, so I run Debian unstable.
The Devuan folks have an uphill battle ahead of them, though. More and more software is getting sucked into the systemd ecosystem because of its heavy-handed policy and vast market share. They might find themselves having to support forks of fairly complex tools just to keep that dependency away.
By the same token, systemd just might make a whole lot of Linux software Unix-incompatible.
Pining for the days when The Glorious MEEPT!!! graced SlapDash with his wisdom.
I don't mind that services have a simple config declaration, with mostly standard start / stop handling. But it would be better to start with some form of "#!/..." so the config file can be used as a script that launches a generic service handler from a traditional init system.
But that's not the only part of the OS that systemd is trying to replace...
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
The exploit is a privilege escalation attack and does not require physical access to the machine. It uses a local account (that is, one on the OS) to start a local root shell (that is, one available to a process running on the machine, not necessarily available over the network).