Bug 1571094 (CVE-2018-1113)

Summary: CVE-2018-1113 setup: nologin listed in /etc/shells violates security expectations
Product: [Other] Security Response Reporter: Doran Moppert <dmoppert>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: alf, karsten, ovasik, pknirsch
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: setup 2.11.4-1.fc28 Doc Type: Release Note
Doc Text:
Setup in Fedora and Red Hat Enterprise Linux added /sbin/nologin and /usr/sbin/nologin to /etc/shells. This violates security assumptions made by pam_shells and some daemons which allow access based on a user's shell being listed in /etc/shells. Under some circumstances, users which had their shell changed to /sbin/nologin could still access the system.
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-06-10 10:20:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1378893, 1571102, 1571103, 1571104, 1571105    
Bug Blocks: 1566628    

Description Doran Moppert 2018-04-24 06:03:33 UTC
setup in Fedora and Red Hat Enterprise Linux added /sbin/nologin and /usr/sbin/nologin to /etc/shells. This violates security assumptions made by pam_shells and some daemons which allow access based on a user's shell being listed in /etc/shells.  Under some circumstances, users which had their shell changed to /sbin/nologin could still access the system.

Note that SELinux and gdm (and probably others) have special-case workarounds for this issue.

Fedora bug:  https://bugzilla.redhat.com/show_bug.cgi?id=1378893

Prior discussions:

 - https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/UCUWTT63JS72R7ROFE46ZVUZLFN3K2MZ/#UCUWTT63JS72R7ROFE46ZVUZLFN3K2MZ
 - https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00887.html

Comment 1 Doran Moppert 2018-04-24 06:15:20 UTC
Created setup tracking bugs for this issue:

Affects: fedora-all [bug 1571103]

Comment 4 Doran Moppert 2018-06-20 03:06:18 UTC
Statement:

Preventing a user from accessing the system without deleting their account is not a simple matter. For utmost security, the account should be deleted. Short of this, we recommend a three-pronged approach:
 * change the user's login shell to a harmless command that is not in "/etc/shells" (for example "/bin/false") to prevent commands being run on their behalf
 * lock the user's password with "usermod -L" to prevent authentication with pam services
 * prevent access to the user's home directory with "chmod 0" or "chown root" and "chmod 700" to prevent authentication with ssh keys etc

Comment 5 errata-xmlrpc 2018-10-30 07:53:13 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2018:3249 https://access.redhat.com/errata/RHSA-2018:3249

Comment 6 alien_life_form 2018-12-11 09:33:25 UTC
The proposed change, as pushed through in setup-2.8.71-10.el7.noarch, breaks large numbers of no-shell ftp only accounts (users that can ftp but not login or ssh in). Besides, the diagnostic given after the change is the incorrect "Wrong password" (rather than, say "login prohibited" or "account disabled"). This is going to give countless sysadmins an hour or so of fun, as complaints about tens of now broken accounts call for a fix. While I feel that - seeing as /etc/shells has existed in its current form for 14 year -  the change should happen in /etc/shells.rpmnew, I also think that the very least, enhanced prominence should be given to the "fix". Also the error message should be improved to adhere to the actual reason of access denial.

Also note that the current way to achieve the present behavior (user cannot have an interactive shell, but can still use ftp) is sticking nologin (or something even less standard, such as /bin/true) in /etc/shells (as no alternative is provided). This means that whatever security enhancements this change intends to put in effect will quickly be undone in several installations.