Bug 22766 - shadow-utils new security issue CVE-2018-7169
Summary: shadow-utils new security issue CVE-2018-7169
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
Whiteboard: MGA5TOO MGA5-64-OK MGA6-64-OK
Keywords: advisory, validated_update
Depends on:
Reported: 2018-03-14 04:54 CET by David Walser
Modified: 2018-03-19 13:14 CET (History)
2 users (show)

See Also:
Source RPM: shadow-utils-4.4-2.mga7.src.rpm
Status comment:


Description David Walser 2018-03-14 04:54:07 CET
openSUSE has issued an advisory today (March 13):

Mageia 5 and Mageia 6 are also affected.
David Walser 2018-03-14 04:54:14 CET

Whiteboard: (none) => MGA6TOO

Marja Van Waes 2018-03-14 07:45:27 CET

CC: (none) => marja11
Assignee: bugsquad => basesystem

Comment 1 David Walser 2018-03-15 20:53:32 CET
Patched packages uploaded for Mageia 5, Mageia 6, and Cauldron.


Updated shadow-utils packages fix security vulnerability:

Privilege escalation in newgidmap, which allowed an unprivileged user to be
placed in a user namespace where setgroups(2) is allowed (CVE-2018-7169).


Updated packages in core/updates_testing:

from SRPMS:

Assignee: basesystem => qa-bugs
Whiteboard: MGA6TOO => MGA5TOO
Severity: normal => major
Version: Cauldron => 6

Lewis Smith 2018-03-17 20:37:23 CET

Keywords: (none) => advisory

Comment 2 Lewis Smith 2018-03-18 13:16:44 CET
Testing M5/64
The package contains these programs to play with, many to be run as root, all with man pages:
- chage - change user password expiry information
- gpasswd - administer /etc/group and /etc/gshadow
- lastlog - reports the most recent login of all users or of a given user
- newgidmap - set the gid mapping of a user namespace [obscure]
- newgrp - log in to a new group
- newuidmap - set the uid mapping of a user namespace [obscure]
- sg - execute command as different group ID

AFTER update to: shadow-utils-4.2.1-6.2.mga5.x86_64

 $ chage -l lewis
 then a list of password expiry parameters.

 # chage root
Changing the aging information for root
Enter the new value, or press ENTER for the default
 then each parameter in turn presented, with default value.

User lewis2 is not in wheel:
 # gpasswd -a lewis2 wheel
 Adding user lewis2 to group wheel
confirmed with MCC that this happened.
 # gpasswd -d lewis2 wheel
 Removing user lewis2 from group wheel
confirmed with MCC that this happened.
But I hit an anomaly here; user lewis2 is shown by MCC & /etc/passwd as being in group lewis GID 1000:
 # grep lewis2 /etc/passwd
but that group does *not* include lewis2. Confirmed by:
 # grep ^lewis /etc/group
 lewis:x:1000:            [would be appended]
 # gpasswd -d lewis2 lewis
 Removing user lewis2 from group lewis
 gpasswd: user 'lewis2' is not a member of 'lewis'
 $ lastlog
Username         Port     From             Latest
root             tty2                      Sad Rha 30 14:28:57 +0100 2017
bin                                        **Never logged in**
 etc etc to
lewis2           pts/1        Sul Maw 19 10:17:13 +0100 2017
siproxd                                    **Never logged in**
 which looks OK.
 $ lastlog -b 100 | grep -v 'Never logged in'
Username         Port     From             Latest
lewis2           pts/1        Sul Maw 19 10:17:13 +0100 2017
$ lastlog -t 100
Username         Port     From             Latest
root             tty2                      Sad Rha 30 14:28:57 +0100 2017
lewis            tty2                      Llu Ion 29 09:50:33 +0100 2018
 all looks OK.

 $ id
uid=1001(lewis) gid=1000(lewis) groups=1000(lewis),10(wheel),969(wireshark)
 $ newgrp wheel
 $ id
uid=1001(lewis) gid=10(wheel) groups=10(wheel),969(wireshark),1000(lewis)
 Looks good, as does the update.

Whiteboard: MGA5TOO => MGA5TOO MGA5-64-OK

Comment 3 Lewis Smith 2018-03-18 21:39:50 CET
Testing M6 x64
It seems I was very wrong in comment 2 about the programs provided by this pkg; they are far more numerous (I doubted the shorter list I got from:
 $ urpmq -l shadow-utils | grep bin | sort -u
), including those listed above plus at least:
The pwconv command converts passwords to the shadow password format.
The pwunconv command unconverts shadow passwords and generates an npasswd file
The pwck command checks the integrity of password and shadow files.
The useradd, userdel and usermod commands are used for managing user accounts.  The groupadd, groupdel and groupmod commands are used for managing group accounts.
+  several more.

I can do more on the M5 front, but for now, M6 AFTER the update:

"By default, pwck operates on the files /etc/passwd and /etc/shadow" (both of which exist), but are not mentioned by:
 # pwck
user 'adm': directory '/var/adm' does not exist
user 'news': directory '/var/spool/news' does not exist
user 'uucp': directory '/var/spool/uucp' does not exist
user 'avahi-autoipd': directory '/var/lib/avahi-autoipd' does not exist
user 'dirsrv': directory '/var/lib/dirsrv' does not exist
user 'powerdns': directory '/var/lib/powerdns' does not exist
pwck: no changes
 Oh well.

 # useradd -g lewis -G wheel -m lewis2      [no p/w]
 # tail -1 /etc/passwd
 # grep lewis /etc/group
 wheel:x:10:lewis,lewis2       [correct]
 lewis:x:1001:                 [but why not here? See c2]
 # grep lewis2 /etc/shadow
 # ls -l  /home/lewis2
 drwx------ 2 lewis2 lewis 4096 Chw  19  2016 tmp/

All this looks OK (group lewis enigma apart). Nor could I log into lewis2 without any password. Oh dear, trying:
 # usermod -p <password> lewis2
I was unable to log in (from a virtual console) at all to lewis2 with any password thus defined.

 # usermod -G wireshark lewis2
 # grep lewis /etc/group
is correct: removed from group wheel, added to group wireshark.
 # usermod -a -G wheel lewis2
 # grep lewis2 /etc/group
is also correct, retaining lewis2 in group wireshark & adding him to group wheel.

 # userdel -r lewis2
 userdel: lewis2 mail spool (/var/spool/mail/lewis2) not found   [OK here]
Removed lewis2 from /etc/passwd | shadow | group (those groups to which he belonged - above). Also removed /home/lewis2. All OK.

 # groupadd lewis2
 # grep lewis2 /etc/group
 # groupmod -n newname -g 1010 lewis2
 # grep lewis2 /etc/group
 # grep newname /etc/group
Correctly changed group name & GID.
 # usermod -a -G newname lewis
 # grep lewis /etc/group
added lewis to group newname.
 # groupdel newname
removes the group, & lewis' association with it.

 # lastlog -b 100 | grep -v 'Never logged in'
 Username         Port     From             Latest
correct: no old logins. Now need to be root for this.
  # lastlog -t 10
 Username         Port     From             Latest
 root             tty2                      Sul Maw 18 20:54:12 +0100 2018
 lewis            tty2                      Sul Maw 18 20:54:01 +0100 2018
Shows only recent logins. Correct.

 $ chage -l lewis
Similar to M5 result c2. OK
 # chage root
Similar to M5 result c2. OK

I cannot believe that the problem of passwords for new user (with or without a password given, I could never log in or su to it) relates to this update. For safety, I am witholding OKs.
I will downgrade the pkg. If that behaviour was there before, I will put both OKs up & validate.

Whiteboard: MGA5TOO MGA5-64-OK => MGA5TOO

Comment 4 Lewis Smith 2018-03-18 22:21:06 CET
M5 & M6 x64

BEFORE both updates:
I reverted to:
and tried all sorts of ways of using the -p password parameter with both useradd (none, specified) and usermod (change), and could never login nor su to the user. I tried from both terminal window and virtual console. Always, I admit, without re-booting; but that should not be necessary.
In all cases, the newly introduced user *was* present in /etc/passwd, /etc/shadow and /etc/group.
This is curious, because I am sure I have used useradd etc successfully in the past, i.e. being able to login to the new user.

Since the post-update behaviour is the same, I am OKing & validating the update.

Keywords: (none) => validated_update
Whiteboard: MGA5TOO => MGA5TOO MGA5-64-OK MGA6-64-OK
CC: (none) => sysadmin-bugs

Comment 5 Mageia Robot 2018-03-19 13:14:29 CET
An update for this issue has been pushed to the Mageia Updates repository.


Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.