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.
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.
"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..."
Systemd is a straight-up copy of the way Windows does things. That to you is "whining about Microsoft"? Making Linux more like Windows is exactly what no one was asking for.
Socialism: a lie told by totalitarians and believed by fools.
This is false, systemd is decentralized into 40 independent executables.
The basic concept of systemd makes sense, you start a list of services first and once that is complete you move onto a seperate list of services . You have unit filed which indicate after target they are a part and which one they depend on. The unit files are simple and easy to understand. An implementation quality issue is a seperate issue from the basic design pattern, the design pattern is a sound concept
You can still use SysV type init on systemd. Disable the systemd unit with systemctl disable servicename and then create a new service in /etc/init.d say /etc/init.d/servicename-sysv and link to in the /etc/init.d/rcX.d directories. that effectively moves the services from systemd to SysV style init.
Also, you can turn on text logging with systemd if you want it.
There are pros and cons to text or binary, it should be up to sysadmin to choose what works best, there is nothing wrong with having a binary capability. One place where binary can help is if you want to store to a database log data so you can have a fast search query or you want to be able to programmatically alter a configuration setting without having to parse and regenerate text files. In these cases some kind of database like SQL can work better than text.
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...