SoylentNews is people
SoylentNews
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 ledow on Tuesday July 04 2017, @11:40AM (2 children)
The problem is also one of username mapping. Just because you're fredbloggs on one machine doesn't mean you're allowed access to anything of fredbloggs on another that happens to have the same username. Do you go by username, or by user ID (which can be mapped differently but it was is encoded on the filesystem for permissions).
At minimum, checking the username is valid using a standardised piece of library code is a no-brainer, rather than making up your own rules.
But just because a specified username exists or not, and acting in a poor way after that point, is just terrible. Why would you do that? Error and fail, or carry on if you're happy as the specified user.
It reeks of "coding for convenience", where if you move a systemd install that doesn't end up on a machine with the right packages/user, rather than error, it just ignores it and carries on as root.
This reinvention-and-redefinition of the wheel is the main reason that something huge, monolithic, and with so many fingers in so many pies, like systemd does, is stupendously bad.
(Score: 2) by Justin Case on Tuesday July 04 2017, @02:59PM (1 child)
(Grandparent)
(Parent)
If the user ID exists it is evidently valid. That decision has been made by the creating-user-ID-thingy. Why would you expect to re-implement that logic elsewhere, to gain nothing?
If the user ID doesn't exist you probably don't want to go spinning up processes under that ID.
So all that is needed is to check if the supplied string is an existing user.
(Score: 2) by PocketSizeSUn on Tuesday July 04 2017, @08:42PM
man 3 getpwnam_r
CONFORMING TO
POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD. The pw_gecos field is not specified in POSIX, but is present on
most implementations.
NOTE
The user password database mostly refers to /etc/passwd. However, with recent systems it also refers to net‐
work wide databases using NIS, LDAP and other local files as configured in /etc/nsswitch.conf.