SoylentNews

Linux systemd Gives Root Privileges to Invalid Usernames

posted by Fnord666 on Monday July 03 2017, @10:12PM   
from the it's-a-feature dept.

MrPlow writes:

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

---

Original Submission

• Re:So let me get this straight (Score: 3, Interesting) by FatPhil on Wednesday July 05 2017, @08:03AM

  by FatPhil (863) <{pc-soylent} {at} {asdf.fi}> on Wednesday July 05 2017, @08:03AM (#535097) Homepage

  A malicious 3rd party could create a package with a legitimate-looking unit file and at least one dodgy executable, but chose to run as an unprivileged user. You trust it initially, as it's running as nobody or thereabouts. However, the uninstallation script in the package could deliberately leave the unit file in place, and one dodgy executable. The account it used is correctly nuked. However, the dodgy executable now runs as root.
  
  OK it requires social engineering to get people to install/try/uninstall, but still, I'd put that as a "fix right now" kind of bug. The brute force "unrecognised user name" = "don't run" solution sounds (a) like a fix to the bug; and (b) like what would have been the sensible default in the first place. If that's more than a trivial 10 line change to the code (I can barely imagine it being more than 3), then it's a code base that needs nuking from orbit.

  --
  Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves

  Parent

  Starting Score:	1		point
  Moderation		+1
  Interesting=1, Total=1
  Extra 'Interesting' Modifier		0
  Karma-Bonus Modifier		+1
  Total Score:		3