Slashdot Mirror
'Severe' Systemd Bug Allowed Remote Code Execution For Two Years (itwire.com)
ITWire reports:
A flaw in systemd, the init system used on many Linux systems, can be exploited using a malicious DNS query to either crash a system or to run code remotely. The vulnerability resides in the daemon systemd-resolved and can be triggered using a TCP payload, according to Ubuntu developer Chris Coulson. This component can be tricked into allocating less memory than needed for a look-up. When the reply is bigger it overflows the buffer allowing an attacker to overwrite memory. This would result in the process either crashing or it could allow for code execution remotely. "A malicious DNS server can exploit this by responding with a specially crafted TCP payload to trick systemd-resolved in to allocating a buffer that's too small, and subsequently write arbitrary data beyond the end of it," is how Coulson put it.
Affected Linux vendors have pushed out patches -- but the bug has apparently been present in systemd code since June of 2015. And long-time Slashdot reader walterbyrd also reports a recently-discovered bug where systemd unit files that contain illegal usernames get defaulted to root.
Affected Linux vendors have pushed out patches -- but the bug has apparently been present in systemd code since June of 2015. And long-time Slashdot reader walterbyrd also reports a recently-discovered bug where systemd unit files that contain illegal usernames get defaulted to root.
Anyone?
That's a problem with Systemd. It's a pretty decent idea with a sub-par execution and a crappy way of dealing with an inherent problem.
Idea: centralized place to optimize startup, management and interconnectivity of all kinds of services.
Problem: some services in their standard form don't quite fit that model.
Solution: let's rewrite them and include as parts of systemd.
The crap part: while the originals were made by experts in that field, the replacements are made by a group of wannabe experts on everything ever, some with overinflated ego. This results in seriously inferior code replacing old 'tried and true' solutions.
At this point, the only real solution I can see is making a fork of systemd, banning the current systemd creators from participating in it, and trimming it to size. If a service doesn't quite fit systemd, work on systemd until it fits, don't rewrite it!
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
No.
My ism, it's full of beliefs.
Story from 5 days ago
"I bless every day that I continue to live, for every day is pure profit."
We told you so.
Anons need not reply. Questions end with a question mark.
When I first read about systemd I thought it was a knock off of the NT service control manager. Except on Windows, that's all it does. It controls services. It starts and stops them. And manages dependencies. And that's it. It doesn't take over the fucking world and try to control everything in the OS. I think this is where systemd lost its way. It's a sad day when we look to Windows as the example of "does one thing and does it well" and not the whole fucking kitchen sink.
This is old news, why don't you publish that story how "Principal systemd developer refuses to acknowledge serious security vulnerability where processes that request to be run as unprivileged user, run as root because Lennyboi does NOT like them start with zeroes! And POSIX be damned, Lenny knows better!"
"centralized place to optimize startup, management and interconnectivity of all kinds of services."
Sorry, thats not how its done in Unix. We don't want a huge monolithic application as init since that brings a huge attack surface to the most important process in the OS, not to mention a bug in a service that doesn't belong there potentially bringing down the entire system.
The summary misleadingly opens with "systemd, the init system", whereas what we're talking about is "systemd-resolved, a part of the SystemD project" (or some such -- I'm a bit vague about the capitalisation TBH).
Anyway, the point is that this bug is not in the init code.
On Debian, we don't even execute this code by default.
So, if you see red and start screaming whenever you see the sequence of characters: s y s t e m d then I'm sorry if you're still reading this, but perhaps you should consider calming down long enough to notice that systemd is both the name of the init program, and the project that also includes a lot of other bits and pieces that are not even needed quite often, and can generally be run without having systemd running as init.
Debian: GNU/Linux done the Linux way
Remote exploits in critical system services? I expect nothing less from the PulseAudio creator.
If you're not familiar with smoke any mirrors from the SystemD PR king, then perhaps these inherent flaws in his projects comes as a surprise to you. But for years a handful of people tried to put the brakes on Poettering and his cronies from hijacking Linux and turning it into his egotistical vision of desktop Unix.
We have failed.
See, this is textbook example of systemd apologists having zero clue about the software they praise.
Is the INIT part of systemd and PROCESS MANAGEMENT "simply better"? Maybe, probably (with the exception of it ignoring invalid values instead of failing to start, like this 0day issue).
But how on gods goddamned earth is reinventing a DNS recursor, which btw is not RFC compliant (per the developer's OWN words it might NEVER be compliant because that idiot has no clue what resolvers really are), any BETTER?!?! It is not better. It is far worse. They're reinventing something they do NOT properly understand and in the process introduce NEW bugs and insecurities, and reinvent OLD bugs that proper resolvers have gone through in the past decades.
Maybe if you would LEARN what systemd really is inside, maybe then you'd see it's a steaming pile of shit that has LONG gone beyond being an init replacement.
The design of systemd is that they all adhere together. Claiming this is somehow not systemd is only slightly less silly than claiming it's not systemd because it's in one of the source files not called "systemd.c".
That's easy. FreeBSD! It is POSIX, UNIX philosophy through and through, and not only completely free of Poetteringitis; it's free of all immature and incompetent vanities and warped design crazes.
The second 'bug' mentioned is far more crazy. The unit file mentions a user that doesn't exist (well, in tfa it is wrongly parsed, even worse), so the default action is to continue as root (instead of supplied user). And this is a good idea because... ??
Why can't this unit action just fail? Wouldn't that be far far better then just deciding to use root, this might cause all kinds of problems. I wonder which other nice surprises and default fall-back action are encoded.
On a long enough timeline, the survival rate for everyone drops to zero.
>> Perhaps we need to get rid of Linux kernel as well.
Nooo, that's a bit over the top.
We only need to integrate the Linux kernel into Systemd.
aaaaaaa
- "Uh? There has been another issue with systemd? Really?"
- "Yeah, but anyway, never mind, we have better things to do."
- "Okay."
Slackware: no systemd, sane defaults, no weirdo patches.
Yeah, it works.
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
Quotes, with minor modifications to make comments more readable, and some text in bold:
... That means a big boon in control for Red Hat.
"Systemd is a poor idea, poorly implemented, in a project that's poorly managed."
"... sure is wilfully, deliberately, and very gratuitously, incompatible with everyone else.
"I doubt Poettering himself understands his role in this, seeing his grasp of architecture, code quality, and so on, so that makes him a 'useful idiot'. He sure does have the personality to pull it off, though. Incompetent arrogance does go a long way, with the right backing."
Systemd, and the poor way it has been presented, had been damaging to Red Hat's reputation ("Dead Hat"). Why did Red Hat management allow that? Is it because Red Hat makes money providing consulting services, and wants Linux configuration to be difficult so that the company will make more money?
Cognitive dissonance translation: You're stuck with it.
The last time I criticized systemd I was accused of being intellectually dishonest.
I'm not sure how being a Linux developer and sysadmin both in my personal life and as a paid employee since 1994 could possibly allow me to intellectually dishonest about any subject having to do with Linux. Dishonesty about Linux could not possibly benefit me in any way.
What I said is that systemd started out being very buggy. Admittedly, to paraphrase Linus Torvalds, they shook most of the bugs out and it works okay most of the time.
Except that systemd changed the way everything has worked for decades, and not for the better.
I could go into specific examples, but suffice it to say that virtually everything that systemd has taken over, it is doing that job poorly. Seeing why services didn't work and making them work has gone from a 5 minute job to something that can take hours. Troubleshooting system problems by looking at logs has become arduous in some cases compared to looking at /var/log/messages or typing dmesg and having your answer in 2 minutes.
systemd needs to slim down and focus on what it does well, initializing weird devices. systemd has no business monkeying around with DNS, and that is just the beginning of the list of things it needs to take a step back from.
Call me intellectually dishonest, but I've been working with Linux for 23 years now (I installed Slackware 2.0 in July of 1994 from a stack of floppy disks) and I haven't failed to learn a thing or two along the way.
At this point its worth asking who controls linux, the community built out of tends of thousands of projects that come together, or a few corporate entities?
For a while now, the corps. Whoever is paying the salaries of developers is in control. Look at the concept of budgeting. Its not necessarily about how to wisely spend money, its also about control. Control by determining how much in the way of resources get allocated to some idea. To prioritize idea. To ensure that work is following the plan developed by senior management, not some plan developed by a consensus of engineers.
Didn't some analysis of commits a while back show most Linux development is corporate funded? Thus corps are in control.
It's things like this that remind us that Lennart is even now still a newbie who thinks in terms of MS Windows. The tool that could create such a username is any text editor, which is something nearly every sysadmin and nearly any long term user of *nix could have told him.
Tarring and feathering would indeed be good -- especially that Lennart as usual insta-closes an obvious and nasty security bug[1] as "non-bug". And when presented with standards documents, he says they don't apply to him [github.com]. Seriously, can someone buy this guy an "Unix for dummies" book? While we don't exactly suffer from a dearth of kooks, this particular kook enjoys having his employer promote his masterpieces even when totally inadequate. The world would be so much better without systemd, PulseAudio and avahi.
Actually nevermind, here's root access.
A 'singular oddity' is an event that cannot be explained and only happens when you are alone.
You must be new here. The Doctrine of the Useful Idiot is referenced these days almost hourly. Hence, you must be really new here.
In this case the "useful idiot" is the trusted repository administrator, who permits a package to be hosted from upstream because it doesn't look suspicious in any way (unless the obscure rule about user accounts with leading digits is top of mind—as if every project doesn't have at least one wonky anomaly, most of which, if pursued, turn out to accord with "who knew?"—and Poettering-appropriate paranoia level is set to deep fat fry).
The trusting user will run the package installer from the trusted repository using "sudo". There's your TRANSITORY, apparently harmless root. No weird system calls. No overt fingerprint of escalation. Mission accomplished. Tick, tick, tick ...
Under Poettering, the principle of least surprise is obeyed by allowing any departure from convention, no matter how thinly understood on the ground where it matters, to lead to an unchecked root escalation.
This was not your father's principle of least surprise.
The long cascade of trusted upstream is become our new Leviathan. Can one even finish a review of inbound patches any more before the next batch arrives?
Software security engineers, eat your heart out. The veritable mascots of unfinishable business sit there drinking tea, while we double down on making things worse.
For the record, Trump is also making a good case for himself as the President of Least Surprise.
This, too, was not your father's least surprise.
This is a serious question. Yes I know there's init, but systemd must have something going for it, otherwise it wouldn't be the default of just about all distros on the planet. ... Faster boot times come to mind.
So, is there an alternative to systemd since everybody seems to be bickering about it? What about a Linux that boots in under 10 seconds? If systemd is so shitty, what's holding people back from developing a system that is better and faster?
Thanks for any input on this.
We suffer more in our imagination than in reality. - Seneca