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.
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
Besides the author who suggests with the title that the bug resides in systemd itself rather than a project included under the systemd umbrella that's disabled by default on most distributions?
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.
On Debian, we don't even execute this code by default.
But Ubuntu does. And the other security hole mentioned in the article does apply to Debian.
As for systemd being more than just an init: the problem lies in it replacing a large set of modular projects with an entangled blob. For example, vdev is an (experimental for now) replacement for udev that fixes a number of design problems, yet good luck using it on a systemd system.
As for running systemd without it being init: systemd-shim is dead, and it was flaky to the point of uselessness even while it lived. You need to recompile the Utopia stack to enjoy basics we used to take for granted like being able to shutdown or suspend from a GUI.
People have tried carving out pieces of systemd to use them separately, like uselessd, yet all such attempts I know of ended in failure because of systemd's blobbiness.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
I can't see how a tape archive could possibly help.
If you gave me a choice between a printer and a giraffe with explosive diarrhoea, i'll get my ladder and my raincoat
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.
It was closed because it has already been discussed at length here:
6237 is about running services as the wrong user, 6259 is about usernames allowed by POSIX but not by systemd.
Do you actually have an argument against his logic here? As in a good reason to follow POSIX rules in this case when Linux in general, which is what systemd follows, does not.
Linux doesn't even know about usernames (just uids), you may at most discuss the behaviour of a particular userland program. And every program I know of (a bunch was tested by someone on IRC) except systemd handles ones starting with a digit correctly, as POSIX prescribes. For some reason, adduser (but not, eg, useradd) dislikes creating new accounts with such a name but all it takes is specifying an option when it relaxes the check from names merely discouraged to ones that are illegal only. No other account creation program complains.
The other reason is that you have to accept any legal external input, and input allowed by the standard is certainly legal. And you need to handle illegal input as well, at the very least by returning an error rather than giving full root access.
any actual argument beyond "he immediately closes bugs I think are obvious!"
That's Lennart's usual response to anything that's not obvious to him. Most of us try to at least research a bug or ask the reporter to explain.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
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.
Not a Lennart critic in general (I usually defend systemd) but I think the GP has a point here.
- The first bug was closed immediately despite systemd treating what Lennart considers an error (debatable) in the worst way possible - escalating a process to root privileges when the user is clearly stating it shouldn't.
- The second bug is an attempt to say "OK, we'll play your game, if you're saying that's correct behavior because of {another issue}, then let's state that {another issue} is also a bug because that's not right either.
In both cases Lennart has immediately closed the ticket without waiting for discussion. He may or may not have reasonable reasons for initially opposing the tickets (he doesn't in the first ticket's case, he absolutely doesn't - root privileges because a username (which you're not even going to bother validating) doesn't look right?! - which is what the GP is complaining about.
This is, frankly, horrifying. systemd is a key part of the GNU/Linux infrastructure, and it exists for a reason: to remove the reliance on shitty, fragile, shell scripts that were all-too-easily made insecure through ignorance or haste. Those who develop it must, absolutely must, listen to and take seriously security concerns. Closing two tickets in a row, immediately, without discussion, concerning a major privilege escalation, still worse because of logic that ultimately boils down to "The user should be smart enough to know some username rules that some developer somewhere pulled out of their arse and which only one or two tools actually enforce", is ridiculously incompetent.
You are not alone. This is not normal. None of this is normal.
So specifically what part of his argument makes you think he doesn't understand this? Because he seems to have addressed your points directly and with reasonable, factually and logically correct arguments.
Well, let's look at his arguements:
First, he said:
Yes, as you found out "0day" is not a valid username.
Which is really damn obviously false, because the relevant standards permit it and various Linux systems permit it. It's only "not valid" as defined by systemd.
Then he says:
1. systemd is not the one coming up with the restrictions on user names, and while some distributions are less restrictive, many do enforce the same restrictions as we do. In order to make systemd unit files portable between systems we'll hence enforce something that resembles more the universally accepted set, rather than accept the most liberal set possible.
Making things "portable" by restricting the configurations that systemd will work with? On what planet does that make any sense at all? It's not like correctly handling user names that Poettering doesn't use is going to break things on his computer; he just doesn't want to make a simple change to fix something because of his ego.
2. User= in unit files is about system users, not regular users, and I am pretty sure we should enforce a stricter regime about system users than regular users.
Since systemd doesn't get to dictate valid usernames, this isn't a reasonable argument.
3. In systemd we generally follow the rule that when we encounter a unit setting that does not validate syntax-wise we'll log about it and ignore it, for compat reasons. We do the same for User= here as for all other options. Note that if you specify a valid user name but where the user doesn't exist, then we'll instead fail the service on start, because in that case there's not just something wrong with the syntax the service author used but actually something inconsistent on the system, and that should be considered fatal.
This just demonstrates a lax attitute towards security. If the unit file specifies a "User=" line, then they obviously want to set a particular user to run the service, and unexpectedly running it as root is a security hole. The fact that Poettering can't see that after 10 seconds of thinking about it tells me that I wouldn't want his code anywhere near my system.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
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.
Neither of us have it backwards. First ticket is Lennart essentially saying "It's OK for systemd to run an application as root when a user specifies an username beginning with a digit because I (Lennart) think the user has made an error, a username shouldn't begin with a digit (his justification being what you're saying.) The second is saying "We shouldn't treat a username beginning with a digit as an error".
It's debatable it is a "Linux" standard to begin with. Only one of the two command line tools to add users actually enforces this supposed rule. Literally nothing else does. The kernel is agnostic. And the command line tools aren't Linux, they're GNU. So what we're looking for is evidence that (1) RMS or an officer blessed by RMS has declared this to be a standard and (2) No declaration since has placed POSIX compatibility ahead of legacy GNU functionality.
Both tickets are entirely reasonable and not one of them should have been closed without discussion. Actually, let me correct that, the first should have been closed with just a note along the lines of "Fuck me! You're right! Personally I think {Inserts personal beliefs about "Linux"'s username policy here} so I'll just have it output an error message and not start the daemon", not "Ha, user is an idiot! LOL ROLF APK!! EVERYONE knows usernames begin with letters LOL! Root privileges for everyone!"
You are not alone. This is not normal. None of this is normal.