| Summary: | <sys-apps/systemd-233-r4: parsing of usernames in unit files results in service running with root privileges | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Kristian Fiskerstrand (RETIRED) <k_f> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | mgorny, rich0, security-audit, systemd, tsmksubc |
| Priority: | Normal | Flags: | stable-bot:
sanity-check+
|
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://ma.ttias.be/giving-perspective-systemds-usernames-start-digit-get-root-privileges-bug/ | ||
| See Also: |
https://github.com/systemd/systemd/issues/6237 https://bugzilla.suse.com/show_bug.cgi?id=1047023 https://github.com/systemd/systemd/issues/6277 https://github.com/systemd/systemd/pull/6300 https://bugs.gentoo.org/show_bug.cgi?id=634688 |
||
| Whiteboard: | B3 [noglsa cve] | ||
| Package list: |
sys-apps/systemd-233-r4
|
Runtime testing required: | --- |
| Bug Depends on: | |||
| Bug Blocks: | 622874 | ||
|
Description
Kristian Fiskerstrand (RETIRED)
2017-07-02 14:28:03 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. (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. 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. (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. (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. I do not intend to diverge from upstream in relation to this "issue". (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. (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 >
> 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.
I'm yielding this bug to systemd maintainers to do what they wish Adding SUSE bug report on similar issue, systemd developers there are working on patch for this behavior at least 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?
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 )
I would be more curious why someone added such a braindead deviation into shadow... 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 (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. 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. (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 (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! 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. (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? (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) (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. 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"}]}]}}
Some details: http://www.openwall.com/lists/oss-security/2017/07/06/16 and https://github.com/systemd/systemd/pull/6300 It appears to me that this is fixed in -234. https://github.com/systemd/systemd/commit/6297d07b82baca4b5602076869477e0de7e1443b 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. 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. amd64 stable ia64 stable arm stable alpha stable x86 stable sparc was dropped to exp. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b5901d8f716555a1479f12313a2925fcadd177a9 ppc/ppc64 stable @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 (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. @maintainers, please clean the vulnerable version =sys-apps/systemd-233-r3 GLSA Vote: No |
