Giving perspective on systemd’s “usernames that start with digit get root privileges”-bug

Fire in the hole! There's a new systemd bug that gets the haters aroused! 

The bug in question is one where systemd's unit files that contain illegal usernames get defaulted to root, so they get run as the root user. It sounds pretty bad;

> In case of bug report: Expected behaviour you didn't see
The process started by systemd should be user previlege

> In case of bug report: Unexpected behaviour you saw
The process started by systemd was root previlege

systemd can't handle the process previlege that belongs to user name startswith number, such as 0day

Let's break it down.

How the bug happens

If you have a systemd unit file that looks like this, the service that should start as the user "0day" will actually be run as the root user.

[Unit]
Description=0day socat service
After=network.target

[Service]
User=0day
Restart=always
Type=simple
WorkingDirectory=/home/0day/
ExecStart=/usr/bin/socat TCP-LISTEN:18086,reuseaddr,fork EXEC:"/opt/run-elf"

[Install]
WantedBy=multi-user.target

This is definitely a bug, because RHEL7 (and thus, CentOS and other derivatives) do allow usernames that start with a digit. It's systemd's parsing of the User= parameter that determines the naming doesn't follow a set of conventions, and decides to fall back to its default value, root.

Just to prove a point, here's a 0day user on CentOS 7.3.

$ cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)
$ useradd 0day
$ su - 0day

$ id
uid=1067(0day) gid=1067(0day) groups=1067(0day)

That user works. The bug is thus in systemd where it doesn't recognize that as a valid username.

Why the big fuss?

If you quickly glance over the bug (and especially the hype-media that loves to blow this up), it can come across as if every username that starts with a digit can automatically get root privileges on any machine that has systemd installed (which, let's be frank, is pretty much every modern Linux distro).

That's not the case. You need a valid systemd Unit file before that could ever happen.

This might be a security issue, but is hard to trigger

So in order to trigger this behaviour, someone with root-level privileges needs to edit a Unit file and enter a "invalid username", in this case one that starts with a digit.

But you need root level privileges to edit the file in the first place and to reload systemd to make use of that Unit file.

So here's the potential security risk;

• You could trick a sysadmin into creating such a Unit file, hoping they miss this behaviour and trick your user in becoming root
• You need an exploit to grant you write access to systemd's Unit files in order to escalate your privileges further

At this point, I don't think I'm missing another attack vector here.

Should this be fixed?

Yes. It's an obvious bug (at least on RHEL/CentOS 7), since a valid username does not get accepted by systemd so it triggers unexpected behaviour by launching services as root.

However, it isn't as bad as it sounds and does not grant any username with a digit immediate root access.

But it's systemd, so everyone loves to jump on that bandwagon and hype this as much as possible. Here's the deal folks: systemd is software and it has bugs. The Linux kernel also has bugs, but we don't go around blaming Linus for everyone one of those either.

I disabled the comments on this post because I'm not in the mood in yet another systemd debacle where my comment section gets abused for personal threats or violence. If you want to discuss, the post is on HackerNews & /r/linux.

Share this post