Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 623532 (CVE-2017-1000082) - <sys-apps/systemd-233-r4: parsing of usernames in unit files results in service running with root privileges
Summary: <sys-apps/systemd-233-r4: parsing of usernames in unit files results in servi...
Status: RESOLVED FIXED
Alias: CVE-2017-1000082
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
URL: https://ma.ttias.be/giving-perspectiv...
Whiteboard: B3 [noglsa cve]
Keywords:
Depends on:
Blocks: CVE-2017-9445
  Show dependency tree
 
Reported: 2017-07-02 14:28 UTC by Kristian Fiskerstrand
Modified: 2018-05-15 19:50 UTC (History)
5 users (show)

See Also:
Package list:
sys-apps/systemd-233-r4
Runtime testing required: ---
stable-bot: sanity-check+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kristian Fiskerstrand gentoo-dev Security 2017-07-02 14:28:03 UTC
See $URL and the see-also for details, basically a unit file that specify a username starting with a digit (in this case "0day") will be silently ignored and run as root against the expectation from the specification in the unit file.

This does, however, not allow arbitrary privilege escalation but requires an installation of unit file (and authorized start). A service that has been started with such a user and not detected it is running as root having a security vulnerability itself, can then run in another privilege zone than the administrator expected, hence tracking it as a security vulnerability.
Comment 1 Richard Freeman gentoo-dev 2017-07-02 15:00:07 UTC
It seems like upstream is sticking to not-a-bug on this one, though we'll have to see if that persists.  

Does Gentoo allow usernames that start with a number?  Apparently a number of tools do not accept these usernames, though POSIX itself apparently seems fine with a username of "0" with a UID other than 0.  I can only imagine what having one of those on your system ends up doing to half the tools out there.
Comment 2 Kristian Fiskerstrand gentoo-dev Security 2017-07-02 15:52:34 UTC
(In reply to Richard Freeman from comment #1)
> It seems like upstream is sticking to not-a-bug on this one, though we'll
> have to see if that persists.  
> 
> Does Gentoo allow usernames that start with a number?  

Rudimentary test shows that at least sys-apps/shadow-4.4-r2 results in 
# useradd -r -m 0day
useradd: invalid user name '0day'

I have not tried other ways of adding a user (including any earlier version of the tools), but this should at least cover manual add in most situations and users added via user.eclass.
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-07-02 17:21:38 UTC
However debatable it may be whether this is a bug, and what exactly is a bug, I certainly don't think this qualifies as a security issue. It's as much of an security issue as user setting 'Users=myfoo' and complaining that systemd did not reject the file with the typo. And Lennart's argument for this 'kinda' makes sense.
Comment 4 Kristian Fiskerstrand gentoo-dev Security 2017-07-02 18:57:53 UTC
(In reply to Michał Górny from comment #3)
> However debatable it may be whether this is a bug, and what exactly is a
> bug, I certainly don't think this qualifies as a security issue. It's as
> much of an security issue as user setting 'Users=myfoo' and complaining that
> systemd did not reject the file with the typo. And Lennart's argument for
> this 'kinda' makes sense.

At the core it violates security architecture principles such as 

CWE-636: When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions. ( https://cwe.mitre.org/data/definitions/636.html ) and;

CWE-250: The software performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses. ( https://cwe.mitre.org/data/definitions/250.html)

Whether it should be treated as a security bug in Gentoo, given identification of mitigating circumstances can however be discussed.
Comment 5 Richard Freeman gentoo-dev 2017-07-02 19:18:04 UTC
(In reply to Kristian Fiskerstrand from comment #4)
> 
> CWE-250: The software performs an operation at a privilege level that is
> higher than the minimum level required, which creates new weaknesses or
> amplifies the consequences of other weaknesses. (
> https://cwe.mitre.org/data/definitions/250.html)
> 

Do we really want bugs filed for every daemon which doesn't launch with the absolute minimum required capabilities?  We don't even do this systematically on systemd though we do accept patches to drop unneeded capabilities.  I imagine doing the same on openrc would be more complicated (compare for example the postfix systemd unit and openrc script).

I'm not sure I'm a fan of the approach that systemd is taking here but it doesn't really seem worth patching systemd to handle this case unless we're going to patch everything else to also handle it and distinguish ourselves as a distro that lets users have numeric usernames.  The alternative is just leaving this bug open until the end of time which also is not going to be helpful.
Comment 6 Mike Gilbert gentoo-dev 2017-07-02 19:22:39 UTC
I do not intend to diverge from upstream in relation to this "issue".
Comment 7 Kristian Fiskerstrand gentoo-dev Security 2017-07-02 19:27:22 UTC
(In reply to Mike Gilbert from comment #6)
> I do not intend to diverge from upstream in relation to this "issue".

I don't think that is useful in this case, either, but depending on how the unit documentation is written, i.e if such behavior is already documented so it is wrong for a system administrator to rely on process being run as a non-privileged user, the answer goes to whether it can constitute a security vulnerability or not. The answer to that is, as it often is, complex, although it doesn't cross any direct security boundaries (good) it can be used as an indirect vector and should definitely be fixed.
Comment 8 Kristian Fiskerstrand gentoo-dev Security 2017-07-02 19:30:29 UTC
(In reply to Richard Freeman from comment #5)
> (In reply to Kristian Fiskerstrand from comment #4)
> > 
> > CWE-250: The software performs an operation at a privilege level that is
> > higher than the minimum level required, which creates new weaknesses or
> > amplifies the consequences of other weaknesses. (
> > https://cwe.mitre.org/data/definitions/250.html)
> > 
> 
> Do we really want bugs filed for every daemon which doesn't launch with the
> absolute minimum required capabilities? 

Yes please (but security auditing likely won't have the resources to systematically do it, but definitely file bugs when encountered)


> I'm not sure I'm a fan of the approach that systemd is taking here but it
> doesn't really seem worth patching systemd to handle this case unless we're
> going to patch everything else to also handle it and distinguish ourselves
> as a distro that lets users have numeric usernames.  

I don't disagree with not patching systemd to handle the case (although it is permitted POSIX), if anything the patch would be for a failure to load the unit file when failing to properly parse it within its expected context.

> The alternative is just
> leaving this bug open until the end of time which also is not going to be
> helpful.

Indeed not a good alternative
Comment 9 Kristian Fiskerstrand gentoo-dev Security 2017-07-02 19:33:10 UTC
> 
> I don't disagree with not patching systemd to handle the case (although it
> is permitted POSIX), if anything the patch would be for a failure to load
> the unit file when failing to properly parse it within its expected context.

just to be clear, if we're satisfied our other tools don't permit such users to be created to begin with (and haven't for a substantial amount of thime) this isn't necessary to do downstream either.
Comment 10 Kristian Fiskerstrand gentoo-dev Security 2017-07-02 20:30:31 UTC
I'm yielding this bug to systemd maintainers to do what they wish
Comment 11 Kristian Fiskerstrand gentoo-dev Security 2017-07-05 11:54:25 UTC
Adding SUSE bug report on similar issue, systemd developers there are working on patch for this behavior at least
Comment 12 Kristian Fiskerstrand gentoo-dev Security 2017-07-05 13:33:38 UTC
It was brought to my attention that althought we don't permit user name starting with 0 we do allow dots in usernames. 

shadow-4.4-r2.ebuild:   "${FILESDIR}"/${PN}-4.1.3-dots-in-usernames.patch
shadow-4.5.ebuild:      "${FILESDIR}"/${PN}-4.1.3-dots-in-usernames.patch

For the sake of it, could someone running systemd see if this is affected by this issue?
Comment 13 Kristian Fiskerstrand gentoo-dev Security 2017-07-05 13:37:55 UTC
src/basic/user-util.c seems to indicate we're affected as well, given:

520 bool valid_user_group_name(const char *u) {
521         const char *i;
522         long sz;
523 
524         /* Checks if the specified name is a valid user/group name. Also see POSIX IEEE Std 1003.1-2008, 2016 Edition,
525          * 3.437. We are a bit stricter here however. Specifically we deviate from POSIX rules:
526          *
527          * - We don't allow any dots (this would break chown syntax which permits dots as user/group name separator)
528          * - We require that names fit into the appropriate utmp field
529          * - We don't allow empty user names
530          *
531          * Note that other systems are even more restrictive, and don't permit underscores or uppercase characters.   
532          */

that is introduced in v323 when this parsing started happening ( 66dccd8d85aac9f029c626aac8d2 )
Comment 14 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-07-05 13:58:31 UTC
I would be more curious why someone added such a braindead deviation into shadow...
Comment 15 Mike Gilbert gentoo-dev 2017-07-05 14:01:41 UTC
Yes, systemd will also ignore usernames containing periods.

Jul 05 10:00:14 naomi systemd[1]: /etc/systemd/system/dummy.service:3: Invalid user/group name or numeric ID, ignoring: a.b
Comment 16 Mike Gilbert gentoo-dev 2017-07-05 14:09:38 UTC
(In reply to Michał Górny from comment #14)
> I would be more curious why someone added such a braindead deviation into
> shadow...

https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/?id=be804d756a1834932c05896a87e6ca2e7c602038

https://bugs.gentoo.org/show_bug.cgi?id=22920

To summarize: someone asked for it, and we modified coreutils (chown) and shadow to make it happen.
Comment 17 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-07-05 14:12:20 UTC
Yeah, I've suspected only one person would have committed something like that. And now there's the question if we can remove it safely, or if we get to hack everything all around the place to conform with the past stupidity.
Comment 18 Kristian Fiskerstrand gentoo-dev Security 2017-07-05 14:16:37 UTC
(In reply to Mike Gilbert from comment #15)
> Yes, systemd will also ignore usernames containing periods.

Its valid POSIX, and quite frankly not that uncommon scheme to have dots in username for firstname.lastname and such
Comment 19 Kristian Fiskerstrand gentoo-dev Security 2017-07-05 14:27:33 UTC
(In reply to Kristian Fiskerstrand from comment #18)
> (In reply to Mike Gilbert from comment #15)
> > Yes, systemd will also ignore usernames containing periods.
> 
> Its valid POSIX, and quite frankly not that uncommon scheme to have dots in
> username for firstname.lastname and such

Sorry, ended up replying to wrong comment, that was a response to Comment 14

Thanks for verifying Mike!
Comment 20 Mike Gilbert gentoo-dev 2017-07-05 14:32:28 UTC
I can see the case for allowing dots, given that we patch that into coreutils and shadow already. However, nobody has asked for it to date, and I would prefer not to carry a patch for it if there is no demand.

Let's wait a bit to see how things shake out elsewhere on the leading-digit issue. That's a behavior change that belongs upstream, not in the distros.
Comment 21 Richard Freeman gentoo-dev 2017-07-05 14:37:21 UTC
(In reply to Kristian Fiskerstrand from comment #18)
> 
> Its valid POSIX, and quite frankly not that uncommon scheme to have dots in
> username for firstname.lastname and such

If that argument hasn't swayed the various upstream projects, why should it sway Gentoo?  Do we really want to have to patch every upstream package that doesn't like periods in usernames, but probably without even bothering to patch them to support the full POSIX character set?

One of the reasons the systemd maintainers deliberately are restricting the character set for usernames is so that people aren't tempted to use names that break other packages.  I'm not sure that this is quite the right way to go about that.

It seems like we ought to have a distro-level strategy around this.  Do we want to patch everything to work with full POSIX usernames, or some subset of POSIX that is actually defined?  Do we want all packages to just follow upstream, and recommend a username specification that works across all of them?  Or do we want random maintainers to patch things one way or another and let people get burnt when something that works in one place fails in another?
Comment 22 Kristian Fiskerstrand gentoo-dev Security 2017-07-05 15:08:22 UTC
(In reply to Richard Freeman from comment #21)
> (In reply to Kristian Fiskerstrand from comment #18)
> > 
> > Its valid POSIX, and quite frankly not that uncommon scheme to have dots in
> > username for firstname.lastname and such
> 
> If that argument hasn't swayed the various upstream projects, why should it
> sway Gentoo?  Do we really want to have to patch every upstream package that
> doesn't like periods in usernames, but probably without even bothering to
> patch them to support the full POSIX character set?
> 
> One of the reasons the systemd maintainers deliberately are restricting the
> character set for usernames is so that people aren't tempted to use names
> that break other packages.  I'm not sure that this is quite the right way to
> go about that.
> 
> It seems like we ought to have a distro-level strategy around this.  Do we
> want to patch everything to work with full POSIX usernames, or some subset
> of POSIX that is actually defined?  Do we want all packages to just follow
> upstream, and recommend a username specification that works across all of
> them?  Or do we want random maintainers to patch things one way or another
> and let people get burnt when something that works in one place fails in
> another?

A generic discussion on that is likely good in mailing lists and maybe for next council to have some policy on, but the current situation is we've supported it for more than a decade so we need to deal with a path forwards (one way or the other)
Comment 23 Richard Freeman gentoo-dev 2017-07-05 15:16:33 UTC
(In reply to Kristian Fiskerstrand from comment #22)
> 
> A generic discussion on that is likely good in mailing lists and maybe for
> next council to have some policy on, but the current situation is we've
> supported it for more than a decade so we need to deal with a path forwards
> (one way or the other)

You've supported it on one or two particular packages.  I wouldn't be surprised if systemd isn't the only one with this issue.

However, we certainly could agree that we'll accept usernames that start with a letter, and subsequent characters are letters, numbers, or periods.  I just think it should be a fairly deliberate policy if we're going to start patching things from upstream behavior, and we should take this stuff into account in general QA/etc.
Comment 24 Kristian Fiskerstrand gentoo-dev Security 2017-07-06 22:11:10 UTC
CVE assigned, re-assigning 


{"data_version":"4.0","references":{"reference_data":[{"url":"
https://github.com/systemd/systemd/issues/6237"},{"url":"
http://www.openwall.com/lists/oss-security/2017/07/02/1"}]},"description":{"description_data":[{"lang":"eng","value":"systemd
v233 and earlier fails to safely parse usernames starting with a numeric
digit (e.g. \"0day\"), running the service in quesiton with root privileges
rather than the user
intended"}]},"data_type":"CVE","affects":{"vendor":{"vendor_data":[{"product":{"product_data":[{"version":{"version_data":[{"version_value":"v223
and
earlier"}]},"product_name":"systemd"}]},"vendor_name":"systemd"}]}},"CVE_data_meta":{"DATE_ASSIGNED":"2017-70-06","STATE":"PUBLIC","ID":"CVE-2017-1000082","ASSIGNER":"
kurt@seifried.org","REQUESTER":"kseifried@redhat.com
"},"data_format":"MITRE","problemtype":{"problemtype_data":[{"description":[{"lang":"eng","value":"CWE-20"}]}]}}
Comment 26 Richard Freeman gentoo-dev 2017-07-12 18:21:42 UTC
It appears to me that this is fixed in -234.

https://github.com/systemd/systemd/commit/6297d07b82baca4b5602076869477e0de7e1443b
Comment 27 Mike Gilbert gentoo-dev 2017-07-12 18:44:18 UTC
234 is going to need some time in ~arch due to some file re-org.

If we are actually treating this as a security vulnerability, I will port it back it to 233.
Comment 28 Mike Gilbert gentoo-dev 2017-07-12 21:04:23 UTC
The fix has been backported to systemd-233-r4. I would like to give it a day or two for testing before we stable it.
Comment 29 Richard Freeman gentoo-dev 2017-07-15 15:45:51 UTC
amd64 stable
Comment 30 Sergei Trofimovich gentoo-dev 2017-07-15 20:28:18 UTC
ia64 stable
Comment 31 Markus Meier gentoo-dev 2017-07-25 18:51:13 UTC
arm stable
Comment 32 Matt Turner gentoo-dev 2017-08-25 22:35:01 UTC
alpha stable
Comment 33 Thomas Deutschmann gentoo-dev Security 2017-08-29 23:38:16 UTC
x86 stable
Comment 35 Sergei Trofimovich gentoo-dev 2017-09-30 08:21:43 UTC
ppc/ppc64 stable
Comment 36 Christopher Díaz Riveros (RETIRED) gentoo-dev Security 2017-09-30 15:45:23 UTC
@Alpha could you please confirm if the package is stable? I can't find any log about that.

@Security please vote and add cve to the database.

@Maintainers please hold cleanup till we have a response from Alpha team. After that proceed to remove vulnerable versions from the tree.

Thank you all.

Gentoo Security Padawan
ChrisADR
Comment 37 Matt Turner gentoo-dev 2017-09-30 23:11:53 UTC
(In reply to Christopher Díaz from comment #36)
> @Alpha could you please confirm if the package is stable? I can't find any
> log about that.

You didn't look in git's log then :)

I see what happened --

commit 23af54f97bd1728c8d6e3281fe23659c23ca2010
Author: Matt Turner <mattst88@gentoo.org>
Date:   Fri Aug 25 15:39:11 2017 -0700
625324
    sys-apps/systemd-233-r4: added ~alpha, bug 625324

 sys-apps/systemd/systemd-233-r4.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

commit 6d427c34916ffd0554e617f83c77df9e85d9127b
Author: Matt Turner <mattst88@gentoo.org>
Date:   Fri Aug 25 11:55:47 2017 -0700

    sys-apps/systemd-233-r4: alpha stable, bug 623532

 sys-apps/systemd/systemd-233-r4.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

The commit for bug 625324 was supposed to rekeyword 234-r3, but I transposed some digits and thus overwrote the earlier commit!

Now fixed.
Comment 38 Aaron Bauman Gentoo Infrastructure gentoo-dev Security 2017-10-08 19:37:23 UTC
@maintainers, please clean the vulnerable version =sys-apps/systemd-233-r3
Comment 39 Aaron Bauman Gentoo Infrastructure gentoo-dev Security 2017-10-08 19:37:32 UTC
GLSA Vote: No