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.
Spot on. After reading Mike Gancarz book The Unix Philosophy, it changed how I did things. I now don't write captive scripts, keep everything in plain text, and write tools that do only one thing well. Truly an eye-opening book.
In case you're interested to know the breakdown...
Politics; n. : A religion whereby man is god.
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.
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,
Slackware ships with a simple, effective BSD-style init populated by simple and readable shell scripts. [....] Install Slackware, and many sysadmin's worries will go away.
You are missing the forest for the trees. What you really want isnt a "BSD-style init", what you really want is BSD.
Linux isnt unix, so dont expect it to maintain the unix philosophy. BSD is unix.
Fun fact: Been true forever
"His name was James Damore."
Have you ever looked at some bash startup scripts? Its difficult to analyse compared to the declarative style. Bash scripts are a much more serious support issue compared to the simplicity of systemd declarative unit files.
Shell, and scripting generally in shell languages, is a key component of all *nix systems. Yes, it's possible to write horrible shell code in an init script, but that's largely the fault of the *author*. Most init scripts are simple; except for whatever custom logic is needed uniquely for this daemon, the rest is boilerplate.
I'd submit that if you can't understand this code, you're not ready to operate or administer a *nix system at the command line or service management debugging level.
https://fedoraproject.org/wiki/EPEL:SysVInitScripts#Initscript_template
Hire a Linux system administrator, systems engineer,