'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.

Comments

Time for tar and feathers?

[chthon]

Anyone?

Re:Time for tar and feathers?

[squiggleslash]

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.

Re:Time for tar and feathers?

[squiggleslash]

One of us has this backwards... It looks to me like in both cases Lennart is saying that systemd follows the Linux standard, not POSIX. Under the Linux rules on usernames they can't start with a number, so using "0day" as a username is invalid and the service won't start because the user doesn't exist.

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!"

Re:Time for tar and feathers?

[aardvarkjoe]

What happens when someone creates a user whose username is purely numeric and that number is different from the uid? What happens when a hacker creates a user with a username of "1" (eg. the uid of root)? Should systemd treat that as root (assuming "1" is a uid) or as the user with username "1" (uid is above 100)?

It would be sensible to disallow creation of all-numeric user names, because of the reasons you stated (far too likely that somebody is doing something nasty.) But disallowing them really doesn't fall under systemd's purview, since systemd is not the manager of the username database. And even if we decided that all-numeric usernames should be disallowed, systemd's totally braindead behavior of granting root access if you try to use one would still be wrong.

In today's environment, we can't afford security to be an afterthought, especially in an extremely pervasive and complex piece of software like systemd.

The problem with systemd

[SharpFang]

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!

Re:The problem with systemd

[Viol8]

"Some of it is even insecure by design "

So because all software has bugs we should just say: "Meh, who cares if systemd is bloated, has monumental feature creep, an author with a serious ego problem who doesn't like fixing them and it replaced an init which, while a bit crusty did what it said on the tin, because, well, systemd." Right?

Wrong. Systemd, is a poor idea, poorly implemented in a project thats poorly managed. Quite why redhat are in thrall to the arrogant little twerp in charge is anyones guess.

Re:The problem with systemd

[SharpFang]

Because "the crap part" is not what is written on the box. Systemd *appears* attractive. The idea is neat. The promise is tempting.

Including systemd in your distro is like preordering No Man's Sky.

Re: The problem with systemd

[Anonymous Coward]

And, security problems + no logs = even bigger problem. Even if he doesn't get why logs are important for security, I wish he would get why they're needed for troubleshooting. It sucks managing a lot of special snowflake servers with systemd since so often error messages don't make it to the journal.

Re: The problem with systemd

[lucm]

Lately I had a flaky service and to get it working I ended up wrapping the daemon in a shell script, and had systemd call that shell script instead. I still had to fight with systemctl because apparently it knows better than me how long a daemon should take to start before giving up, but I managed to get it working *in spite* of systemd.

Now I have a Docker-first policy and for the most part it's to avoid dealing with systemd.

Surprised?

[MrKaos]

No.

From all of us Linux greybeards:

[Gravis Zero]

We told you so.

No, its not a pretty decent idea

[Viol8]

"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.

Re: Now it becomes clear...

[Anonymous Coward]

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.

What a load of bollocks.

[Anonymous Coward]

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".

Re:Better distro suggestions?

[fnj]

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.

Meanwhile in Slackware land...

[Noryungi]

- "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.

Why does Red Hat allow damage to its reputation?

[Futurepower(R)]

Quotes, with minor modifications to make comments more readable, and some text in bold:

"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. ... That means a big boon in control for Red Hat.

"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?

Re:"Intellectually dishonest"

[Anonymous Coward]

I started with Unix in 1982.

Systemd fails many of the basic Unix concepts. Small, interconnectable tools, text log files, human readable configurations.

MS Windows attitude

[dbIII]

With one of those links Lennart wrote:

Yes, as you found out "0day" is not a valid username. I wonder which tool permitted you to create it in the first place ... So, yeah, I don't think there's anything to fix in systemd here.

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.

Who the fuck are you?!

[GeekWithAKnife]

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.