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.
"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!"
That's not a bad idea - meanwhile, Poettering's response (presumably): "Systemd is working as expected. This is a flaw in {bind/whatever}. Bug closed."
They sentenced me to twenty years of boredom
Story from 5 days ago
"I bless every day that I continue to live, for every day is pure profit."
If a service doesn't quite fit systemd, work on systemd until it fits, don't rewrite it!
Part of the appeal of the systemd is that it minimises the idiosyncrasies of all the different tools. You don't have to rewrite the services, but fitting them to systemd is reasonable. For example, udev was not rewritten, just integrated.
originals were made by experts in that field
Whatever made you say that? There are no mandatory security audit, secure coding practices, mandatory code reviews, qualification certificates or anything like that in free software. Some of it is even insecure by design (I'm looking at you, X.org). systemd will get rid of these bugs eventually as time goes on.
Of course, all theses problems could have been avoided, if it had been written in C++14 or rust from the beginning. (And yes, that was sarcasm. Sorry.)
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.
There are problems with that idea:
* Red Hat is backing Systemd and this is the only thing Lennart seems to work on. You'll be in the quagmire of always trying to catch up on new shitty features and broken compatibility.
* Systemd was 250K+ LoC last I checked
* Systemd's source code is poorly documented at best.
* Systemd has a overly clever design that makes it difficult to grok.
I'm not saying that Systemd shouldn't be replaced, I'm saying that you need to discard the original.
Anons need not reply. Questions end with a question mark.
systemd is broken by design, and despite offering highly enticing improvements over legacy init systems, it also brings major regressions in terms of many of the areas Linux is expected to excel: security, stability, and not having to reboot to upgrade your system.
Don't be dense.
Anons need not reply. Questions end with a question mark.
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
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: https://github.com/systemd/sys...
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.
I'm not saying he is right, merely that your statement gives a false narrative of what actually happened and that you don't seem to have any actual argument beyond "he immediately closes bugs I think are obvious!"
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
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.
My guess is it's the sunken cost fallacy - in the beginning they didn't realize just how many flaws their idea had, and once they got the thing running initially, they would not admit the failure (ego problem).
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
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?
heh. It IS important in Linux for embedded. You switch your Linux toaster on, or whatever you have running Linux, you want it up and toasting in 10 seconds max.
But the approach is totally misguided because Systemd alone adds so much overhead any benefits it might bring are lost on time spent loading Systemd, all its configurations and dependencies. The actual approach is init with custom inittab consisting of 5-6 lines that start only the bare essentials you need. Systemd is the kind of cure that is worse than the disease.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
The rules for Linux user names say they must not start with a digit,
Where are you finding this documented?
As you have been informed repeatedly in this thread, the Linux kernel doesn't even use the concept of user names (it works with IDs instead), so your statement can't possibly be true. Apparently one particular tool, adduser, by default, enforces some extra rules, but that doesn't mean that those rules are universal to all Linux systems.
Linus has a rule "don't break userspace." Poettering's rule is apparently "let's break userspace every chance we get for no damn reason at all."
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
That page says:
It is usually recommended to only use usernames that begin with a lower case letter or an
underscore, followed by lower case letters, digits, underscores, or dashes. They can end
with a dollar sign. In regular expression terms: [a-z_][a-z0-9_-]*[$]?
Note the use of the word "recommended." Not "required", or "mandatory." You're misinterpreting a convention as an actual rule.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?