Bug 32285

The advisory-bugzilla entry shows shadow-4.8.1 as the fix... which we have had since Aug 2021.

Assigning globally as no packager in view for this SRPM.

Assignee: bugsquad => pkg-bugs
Status comment: (none) => ? Fix v4.8.1

Suggested advisory:
========================

The updated packages fix a security vulnerability:

Potential password leak. (CVE-2023-4641)

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4641
https://www.suse.com/support/update/announcement/2023/suse-su-20233591-1/
========================

Updated packages in 9/core/updates_testing:
========================
lib64subid4-4.13-1.1.mga9
lib64subid-devel-4.13-1.1.mga9
shadow-utils-4.13-1.1.mga9

from SRPM:
shadow-utils-4.13-1.1.mga9.src.rpm

Updated package in 8/core/updates_testing:
========================
shadow-utils-4.6-4.2.mga8

from SRPM:
shadow-utils-4.6-4.2.mga8.src.rpm

Status comment: Fix in version 4.14.0-rc1 => (none)
Assignee: pkg-bugs => nicolas.salguero
Status: NEW => ASSIGNED
Version: Cauldron => 9
Whiteboard: MGA9TOO, MGA8TOO => MGA8TOO

MGA8-64 Xfce on Acer Aspire 5253
No installation issues.
Ref bug 31198 Comment 8
# useradd prutser
# getent passwd {1000..60000}
tester8:x:1000:1000:Tester8:/home/tester8:/bin/bash
prutser:x:1001:1001::/home/prutser:/bin/bash
[root@mach7 ~]# usermod -p pruts prutser
Now as normal user in second terminal tab
$ su -l prutser
Password: 
su: Authentication failure
repeated to exclude finger trouble, no avail
Used MCC to handle users, prutser is there, changed password to pruts there and then  the su command works
$ su -l prutser
Password: 
[prutser@mach7 ~]$ pwd
/home/prutser
Continuing test
# userdel prutser
userdel: user prutser is currently used by process 9350
That's right, prutser is still logged in in the other terminal tab
Giving the exit command there and then
# userdel prutser
no feedback, that's OK
Checked in MCC, prutser is gone
# getent passwd {1000..60000}
tester8:x:1000:1000:Tester8:/home/tester8:/bin/bash
Can someone explain why I couldn't login after the usermod command???

CC: (none) => herman.viaene

MGA9-64 Xfce on Acer Aspire 5253
No installation issues.
Exactly the same commands and results as in Comment 3 above.
If someone could explain why the uermod command does not give the result I expected, I will give the OK, but for now I don''t trust this behavior.

(In reply to Herman Viaene from comment #4)
> MGA9-64 Xfce on Acer Aspire 5253
> No installation issues.
> Exactly the same commands and results as in Comment 3 above.
> If someone could explain why the uermod command does not give the result I
> expected, I will give the OK, but for now I don''t trust this behavior.

Asking for feedback, because no one replied

CC: (none) => marja11
Keywords: (none) => feedback

(In reply to Herman Viaene from comment #3)
> Can someone explain why I couldn't login after the usermod command???

According to the man page of the usermod command:
       -p, --password PASSWORD
           defines a new password for the user. PASSWORD is expected to be
           encrypted, as returned by crypt (3).

           Note: Avoid this option on the command line because the password
           (or encrypted password) will be visible by users listing the
           processes.

           The password will be written in the local /etc/passwd or
           /etc/shadow file. This might differ from the password database
           configured in your PAM configuration.

           You should make sure the password respects the system's password
           policy.

For me, that command should not be used at all, because encryption with the "crypt" command is weak.  The command that must be used is "passwd".

Keywords: feedback => (none)

Advisory from comment 2 added to SVN. Please remove the "advisory" keyword if it needs to be changed. It also helps when obsolete advisories are tagged as "obsolete"

@ hviaene,

Now that you have the explanation about the usermod command, can you give the OKs ?

Keywords: (none) => advisory

Herman, is it OK on MGA8, as well?

CC: (none) => andrewsfarm

Well, I agree on the OK, with the remark that "next time" we should have a closer look at the other commands of this package to test it. This test as applied now is, let say politely, now less than adequate.

Whiteboard: MGA8TOO MGA9-64-OK => MGA8TOO MGA9-64-OK MGA8-64-OK

@hviaene: Noted.

Validating.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2023-0294.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED