[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 5 Jul 2017 10:50:34 +0200
From: Pali Rohár <pali.rohar@...il.com>
To: oss-security@...ts.openwall.com
Cc: Daniel Skowroński <daniel@...nf.net>
Subject: Re: systemd fails to parse user that should run
service
On Sunday 02 July 2017 12:02 Daniel Skowroński wrote:
> Hi all,
>
> Just wanted to bring attention to issue with systemd not doing what is
> expected when parsing User that should run service.
> When it fails to parse string starting with digit it fails back to root
> causing obvious threat to security.
>
> See discussion with developer on github:
> https://github.com/systemd/systemd/issues/6237
>
> Best,
> -Daniel Skowronski
Hi!
There are basically two problems:
1) In more Linux distributions useradd tool allow to create a new user
which starts with digit. Also according to POSIX such user name is a
valid. This means that valid user name (for some Linux distributions)
from /etc/passwd specified in systemd unit file results running service
as root user.
2) If user name specified in systemd unit file is syntactically correct
(according to systemd check) but user name does not exist then systemd
refuse to start that unit.
Which leads to problem that syntactically invalid user name (for
systemd) results in root user and syntactically valid non-existent user
name cause error.
Because check if user name is valid is different in systemd as specified
in POSIX and also different as in useradd tool supplied by some Linux
distributions, I see this as a security problem when processing invalid
input from configuration unit file.
Correct behaviour should be to throw error also when garbage (invalid
user name), according to internal systemd check, was specified. And not
start service under root user with high privileges.
Because of this I would suggest to ask for CVE identifier, so Linux
distributions can mitigate or decide how to handle this problem.
Linux distributions which follow POSIX standard when creating new users
are affected by this.
Please note that above bug tracker on github is locked for future
discussion, which means it is not possible to ask for more details or
continue discussion in upstream.
Which is really *bad* for security related problems.
What do you think, how should be this problem handled?
--
Pali Rohár
pali.rohar@...il.com
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
