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.
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'
"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.
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.
I heartily recommend Devuan.
Knowledge is power; knowledge shared is power lost.
the one thing I learned at the place I work is that people and businesses are not rewarded for perfect code -- trouble-free code results in the project being thought of as small and not valuable -- if you want money, you need to build complex and buggy code - systemd supporters are no dummies and know what it takes to earn more money
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.
Perl is a language. It doesn't do anything on it's own. Executing on the language is the "do one" thing and a completely open interface.
find, well, finds things. I don't think finding /only/ "one" kind of thing and doing that "well" would make any sense. The "find" is the thing it does. That makes sense. Are you suggesting 'find' means something different?
tar as we know is Tape ARchive. It's a backup tool. Wait, what you don't want to use it to backup things? ... what would make it not go saving off things? Are you on crack?
SystemD is a ... is a... forget it. It's a BLACK BOX.
You tell someone not initiated into the command line a unix command like "find" or tell someone what TAR stand for and tapes are actually backup devices, and they get an immediate image of what it does, no class or degree needing. You mention how linux is cool and shiny because of System D, not to mention fast, they'll give you blank stares and start thinking all the stereotypes in existence.
Now I'm not saying all UNIX stuff really matters or is done well either or understood by non-techies, but you are saying our argument of the UNIX way is invalidated by how things are really done in UNIX? What UNIX are you using? Call it Linux, it was designed to mimic UNIX, and still mimics it, except now we are getting MS-lite wannabe distros added to the mix. Whatever.
I don't think the UNIX philosophy was ever intended to be a design spec, but inspiration of ideas that work because of their simplicity. It is compatible with building of things of complexity too. But disparage it and make computers non-accessible appliance-like System D devs have to even mainstream techies, just because, and fill it full of marketing features to sell your distro at your peril.