Submitted via IRC for TheMightyBuzzard
A bug in Linux's systemd init system causes root permissions to be given to services associated with invalid usernames, and while this could pose a security risk, exploitation is not an easy task.
A developer who uses the online moniker "mapleray" last week discovered a problem related to systemd unit files, the configuration files used to describe resources and their behavior. Mapleray noticed that a systemd unit file containing an invalid username – one that starts with a digit (e.g. "0day") – will initiate the targeted process with root privileges instead of regular user privileges.
Systemd is designed not to allow usernames that start with a numeric character, but Red Hat, CentOS and other Linux distributions do allow such usernames.
"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," explained developer Mattias Geniar.
While this sounds like it could be leveraged to obtain root privileges on any Linux installation using systemd, exploiting the bug in an attack is not an easy task. Geniar pointed out that the attacker needs root privileges in the first place to edit the systemd unit file and use it.
[...] Systemd developers have classified this issue as "not-a-bug" and they apparently don't plan on fixing it. Linux users are divided on the matter – some believe this is a vulnerability that could pose a serious security risk, while others agree that a fix is not necessary.
See, this is why we can't have nice init systems.
Source: http://www.securityweek.com/linux-systemd-gives-root-privileges-invalid-usernames
(Score: 2) by requerdanos on Monday July 03 2017, @10:33PM (7 children)
If you have to already have root to potentially later get root, there are much easier ways to do it than this. A single suid binary, for example.
(Score: 5, Insightful) by The Mighty Buzzard on Tuesday July 04 2017, @01:48AM (5 children)
The problem isn't that someone could write a malicious unit file, it's that someone could typo "apahce" and your web server would end up running as root. Substitute your possibly exploitable daemon of choice for apache.
My rights don't end where your fear begins.
(Score: 4, Informative) by jimshatt on Tuesday July 04 2017, @07:29AM (4 children)
To rehash your explanation: this isn't an attack vector in itself, because you'd need root to create a malicious init file, but a minor bug in a misconfigured daemon can now suddenly be a gaping security hole.
(Score: 2) by The Mighty Buzzard on Tuesday July 04 2017, @10:24AM (2 children)
Cheers for the correction.
My rights don't end where your fear begins.
(Score: 2) by Justin Case on Wednesday July 05 2017, @05:47PM (1 child)
Fucking brilliant new signature! I might borrow it if you get tired of it someday.
(Score: 2) by The Mighty Buzzard on Wednesday July 05 2017, @05:55PM
Go for it. Just remember I stole it first.
My rights don't end where your fear begins.
(Score: 1, Informative) by Anonymous Coward on Tuesday July 04 2017, @10:30AM
It's not related to starting with a numeric character, it's any invalid (in systemd's view) username, including typos such as apaché.
The problem with usernames starting with a digit is that those are actually VALID usernames in a posix system, but systemd does not consider them valid. So the fully valid username 0access get root access instead.
So it's actually two bugs - the security hole that regards any invalid username as root, and the bug that treats any username that starts with a digit as invalid.
(Score: 1) by Deeo Kain on Tuesday July 04 2017, @09:32PM
SUID binaries are too easy to spot. Every hardening package searches and neutralizes them.