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.
We told you so.
Anons need not reply. Questions end with a question mark.
"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.
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.
- "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?
I started with Unix in 1982.
Systemd fails many of the basic Unix concepts. Small, interconnectable tools, text log files, human readable configurations.
In systemd, if a unit fails, the ENTIRE init system fails and your system boots in emergency mode.
And that is worse than allowing full escalation to root in what way?
The problem with that development team is a focus on single user laptops and desktops where it doesn't really matter if the user has full root access. They should be paddling in the shallow pool of MS Windows 10 instead of changing something people want to use for servers.
You're too stupid to understand this. The vulnerable vector is not someone creating a user on your system. The vulnerable vector is not someone installing a unit file without your knowledge.
The vulnerable vector is in TIRED admin typing User= and accidentally starting it with 0. The vulnerable vector is process intended to run unprivileged, running as root.
AND WHY?
ONLY BECAUSE the systemd developer is too arrogant to admit his little shit of a product parses values wrongly.
* Forget POSIX
* Forget whether useradd or shadowutils may or may not allow creating usernames that start with 0
* Forget politics, reasons, distros
* Forget EVERYTHING except ONE little thing: "0string" is ** NOT ** a valid integer value, so don't treat it as one.
Your shitty little parser is WRONGLY parsing the value of User= field. It does not take the WHOLE value in consideration but only the numeric part of it. There is not a single situation where you'd want your program to do that. Absolutely no excuse, no use case, nothing, where "0day" is taken AS A VALID NUMBER 0, regardless how it got there.
garbage-in = garbage-out. That makes systemd a GARBAGE DISPENSER, because it allows garbage-in without validating it.
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.
The problem is not having to wait a few ms for syslog to startup, the problem is that syslog have dependencies (like i.e access to a file system) that needs to be up before it can be started and thus everything that logs before that is missed unless something else does it.
And journald is not something that "everyone hates", some people here on Slashdot does yes, but there are lot's of people out in the real world who uses it and prefers it to the old syslog. I was myself quite sceptical when journald was announced with binary files but now that I've used it for some time I do realise that there are things it does and that it does well that would be just impossible or extremely complicated to do with the old syslog text format (i.e that the journal catches all output from stdout and stderr and joins it with the syslog output by adding the unit name in the meta-data, or that you can search for all logs produced by a special unit without accidentally get logs from other applications mixed in due to them matching the same grep pattern).
How are the unit files not "human readable configurations", especially when compared with the old sysv init scripts?