
Systemd’s “usernames that start with digit get root privileges” bug - Mojah
https://ma.ttias.be/giving-perspective-systemds-usernames-start-digit-get-root-privileges-bug/
======
comstock
The article says:

"Should this be fixed? Yes, it's an obvious bug"

The author of systemd says:

"So, yeah, I don't think there's anything to fix in systemd here. I understand
this is annoying, but still: the username is clearly not valid."

And that's basically the problem. Not that the bug exists. But the systemd
author doesn't recognize it as such, and refuses to fix it. This seems to be a
recurring theme with systemd.

~~~
kps

      > the username is clearly not valid.
    

It _was_ , until systemd said it wasn't.

~~~
rnhmjoj
I understand the criticism towards systemd but let's not start making things
up. From useradd (8) manual:

"Usernames must start 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_-]*[$]?"

~~~
kps
As dlgtho notes, your system's useradd(8) man page is not a description of all
existing systems. Historically, the prohibitions were against ‘:’ (breaks
passwd(5)), initial ‘-’ (mistaken for an option by login(1)), and upper case
without lower case (makes getty(8) think you have an upper-case-only
terminal).

(Not much point in continuing this, since the post has dropped from front page
to 7th in half an hour, and will never be seen again.)

~~~
rnhmjoj
My bad, I though this was somewhat standard.

~~~
JdeBP
What the standards say supports that assertion even less than what the other
manual pages say. There _is_ a standard for this. It is IEEE 1003.1 a.k.a. The
Single Unix Specification.

* [http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_...](http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_437)

* [http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_...](http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_282)

Valid portable user names can have digits and letters intermixed. They are
simply restricted to not starting with a minus.

* [https://github.com/systemd/systemd/issues/6237](https://github.com/systemd/systemd/issues/6237) ([https://news.ycombinator.com/item?id=14681377](https://news.ycombinator.com/item?id=14681377))

In the actual bug report, as opposed to Mattias Geniar's article headlined
here, this is already mentioned.

------
mamon
Setting aside issue with user names starting with a digit: Why on earth would
anyone use "root" as default, fall back value for user name? In case of
unparseable/unrecognized value the sane thing to do would be to raise an
error.

~~~
code_duck
My impression is that the script is being run as root. It's going along,
running everything as root... It encounters an attempt to run a command as a
different user, and being unable to find a user matching that, says okay,
whatever, I'll just run that as root too.

~~~
detaro
If it can't find a matching user, it aborts as an error. When it doesn't think
the value could possibly be a valid user, _then_ it ignores the rule to run as
a different user completely.

~~~
digi_owl
So systemd is once again second guessing everything else...

~~~
detaro
I didn't say it's a good idea to do that, just wanted to clarify what the
specific behavior is.

------
peterkelly
Another attack vector: An administrator deliberately creates a user starting
with a 0, for example if they chose to name it after a system they are using
(e.g. www.0xproject.com).

They assume that the program is running as a user with limited privileges.
Then, an exploit gets found in that program, and now instead of an attacker
gaining user-level access, they now have root-level access.

By far the most worrying part of the issue for me was that the developers said
"oh it's not a bug" and just closed the issue, without properly thinking
through the implications of the behaviour (such as the other attack vectors
mentioned here). That's gross negligence.

~~~
wolco
I agree finding a bug is part of the development lifecycle. Having the
developer just close the bug and claim its not an issue is the worrisome part.
When the next bug is found there is less reason to report it.

------
bigbugbag
I don't know the author and he does not provide context, so I don't really get
what the fuss is about. Mentions haters, personal threats of violence but this
looks like the usual: a bug in systemd due to an incorrect assumption by the
developers, proposed solution: decide that there is no bug and systemd is
correct, the use case is wrong.

I experienced one first hand, a definition in fstab for a removable drive
suddenly (after a systemd update and no warning) caused the computer to fail
at boot time because the removable drive was not present. The fun part is that
the emergency shell had a bug too that prevented itself from starting and
looped to infinity instead.

It was nice to have to drive 6h each way to deal with this systemd new
"feature".

------
falcolas
Err, there are such things as user level systemd unit files[0]. I have no idea
if this bug gets triggered by those as well, but it's a pretty big deal if it
is.

> There's a new systemd bug that gets the haters aroused!

Oiy... I feel like I am walking into the middle of a Vim/Emacs flame war. Very
unfortunate.

[0]
[https://www.freedesktop.org/software/systemd/man/systemd.uni...](https://www.freedesktop.org/software/systemd/man/systemd.unit.html#id-1.7.5)

[EDIT] As noted downstream, the parsing error causes the 'User=' directive to
just be ignored, so a user unit file will be run by the user. Still too many
vectors of attack, sadly.

~~~
the_mitsuhiko
> I have no idea if this bug gets triggered by those as well

Why should it? The bug is not that it runs as root but that it encounters a
parsing error and uses the default. The default for root is root and the
default for user A is user A.

~~~
falcolas
> Why should it?

Thank you for the correct, if condescending, answer. It was unclear from the
original bug, or this article, if it was falling back on a hardcoded 0 or the
user used when the directive is not present.

Since systemd's own behavior is inconsistent, I can't depend on that behavior
to derive the reasonable answer. That inconsistency stems from the fact that a
"valid" user name that doesn't exist triggers different behavior than an
"invalid" user name; and the definition of "valid" is different between
systemd and the rest of Linux.

------
hueving
The attack vector this article doesn't mention is systems where systemd unit
files are generated automatically.

For example, on some shared clusters I used there was a capability to request
a service run as your user. This was before systemd at the time so it would
end up generating an /etc/init.d entry, but I imagine a modern equivalent
might generate a unit file.

So this article downplays the vulnerability a bit by claiming you have to
trick a sysadmin when you could actually just use an automated service
management system.

------
Grue3
[https://github.com/systemd/systemd/issues/6237#issuecomment-...](https://github.com/systemd/systemd/issues/6237#issuecomment-311900864)

There are no words. How can someone so obviously incompetent be in charge of
such an important open source project? Unless he's hired by some 3-letter
agency to leave as many security holes in systemd as possible.

------
throwanem
Why will systemd start a unit it can't sensibly parse? If it thinks the user
is invalid, shouldn't that be a fatal error?

~~~
digi_owl
Sometimes it will, sometimes it won't.

If you mangle the dependency chain in any way, you are likely to find yourself
looking at the emergency console.

------
viraptor
Another vector: some services may create users and services on request. You
don't have to trick the administrator to setup the account if the main purpose
of some SaaS/PaaS is to take user's code and run it in local environment -
possibly as a service, with the username controlled by the user.

------
moomin
May I propose Moomin's Law: Any statement about how hard a security issue is
exploit is unlikely to be true unless made by someone who has exploited it.

------
moe
Systemd is the disaster that happens when we ignore the lessons of UNIX.

UNIX is all about small, composable tools. Do one job and do it well.

One of these tools didn't stand up to the test of time (SysV init) and needed
to be replaced.

We could have chosen one of the mature candidates (upstart, runit, minit) or
even built a great new one from scratch. Life would have been good.

But instead we ended up with this trainwreck of a monolith that not only
replaced init, but at the same time tried to reinvent almost every critical
userspace daemon from Syslog to NTP.

It predictably failed on every metric.

Now it is time for the major Linux distributions to conclude this experiment,
roll back the Systemd mistake and return to the modularity that made UNIX
successful.

~~~
e40
Perhaps someone can explain why it was chosen as the replacement for SysV
init, when all of the parent's comments/critiques of systemd were known in
advance of it being pulled into major distros.

~~~
digi_owl
Bundling.

systemd as a package is more than just init.

It is init, inetd, session manager (logind), udev, dns client, dhcp client,
cron, su, and the list keeps growing.

Basic thing is that first of all Poettering to it a toehold at Fedora (he
works at Red Hat, so surprise surprise). Then he offered Gnome the code for
supporting logind on a silver platter.

End result is that to offer Gnome as the desktop you either have to patch it,
shim it (ask Canonical how well that worked out) or adopt systemd.

Effectively what is happening is that Fedora is becoming the de-facto standard
for Linux. In part because it is effectively the testing distro for Red Hat
Enterprise Linux, and thus a large portion of userland devs (and a number of
kernel devs) use it as their "dogfood".

------
JdeBP
The original bug report is already on Hacker News as
[https://news.ycombinator.com/item?id=14681377](https://news.ycombinator.com/item?id=14681377)

------
notacoward
To me, this reflects as much on "many eyes make all bugs shallow" as on
systemd. How many have used this feature without noticing that it has a
serious bug? How many pairs of eyes have even passed over that particular
piece of code without seeing what was wrong with it? More eyes only make bugs
shallow when they're trained and diligent eyes.

------
digi_owl
Sadly it seems the "gamersgate" mob has latched onto systemd as another
controversial topic to toy with...

~~~
dijit
I'm having difficulty following the mental gymnastics required to follow your
statement.

Are you saying everyone you disagree with is "gamer gate"?

~~~
digi_owl
No, i am saying that at the height of gamersgate there seemed to be a mob of
people that went around harassing (trolling if you will) the people involved
simply because they found doing so amusing.

And gamersgate lost media attention, my impression that a sizeable chunk of
that mob has latched onto systemd as their target.

The problem is that the people being harassed can't separate the harassers
from the people voicing actual complaints, lumping them all into the
trolls/haters bin.

And frankly gamersgate was just the "peak" of a sorts, the root of it all lay
further back. It is basically a mutated, nastier, form of the antics done
under the "anonymous" moniker.

~~~
dijit
"Gamer gate" has absolutely nothing to do with legitimate criticisms of
systemd.

I am not a gamer, I have never trolled. I am a sysadmin in an 11,000+ person
organisation and I have qualms with systemd.

And frankly speaking, proponents of systemd usually fobbed us off by saying
that we're dinosaurs. Or intentionally misrepresenting our arguments.

Now we're being fobbed off as being some weird gaming industry crap? No.

~~~
digi_owl
Now you are misrepresenting what i am saying.

I think there are legitimate complaints against systemd.

but at the same time i also think there is harassment going on.

From our side of the fence it is easy to tell the two apart.

But from the systemd developer side, and apparently also the systemd proponent
side, the two intermix.

This akin to how hooligans join protest marches simply to start fights and
riots, knowing it will be blamed on the legitimate protesters.

------
udsloiwdaa
/. is gonna have a field day.

~~~
digi_owl
Nah, the bots will make sure the pro views get all the insightful votes...

