Bug 1965345
| Summary: | out of root access on local system | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Stas Sergeev <stsp2> | ||||
| Component: | libxcrypt | Assignee: | Björn Esser (besser82) <besser82> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | rawhide | CC: | besser82, fweimer, ipedrosa, pvrabec, sahana, ssorce, szidek, tm | ||||
| Target Milestone: | --- | Keywords: | Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | libxcrypt-4.4.22-2.fc34 libxcrypt-4.4.22-2.fc33 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2021-06-26 01:00:42 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Stas Sergeev
2021-05-27 13:46:43 UTC
Created attachment 1787676 [details]
screen-shot of chage -l
Managed to hack into the system
with the boot tricks.
Still can't hack out root under
GUI, so had to photo the screen-shot.
It clearly shows that all restrictions
and agings are disabled on my passwords.
And yet, after an update, I suddenly
can't log in because everything got
"expired"...
This appears to be the PAM bug. After adding no_pass_expiry to pam_unix.so in /etc/pam.d/system-auth some login scenarios started to work, namely "login -f" started to work. But still not the normal login. But after I changed account required pam_unix.so to account required pam_permit.so things started to work as before. So obviously pam_unix.so is broken. pam-1.5.1-5.fc35.x86_64 This is a bug with libxcrypt 2.2.41. There is already a build of v4.4.22 available, which should fix this issue. *** This bug has been marked as a duplicate of bug 1965149 *** No, its not fixed. Upgraded to libxcrypt-4.4.22-1.fc35.x86_64 sudo now works - big relief. user login now works - also good. su still doesn't work: Password: You are required to change your password immediately (administrator enforced). Current password: root login still doesn't work. In a mean time, let me note that this is the worst bug I've ever seen. Not too many people will come for an update: they will just lose their system. Is this change in libxcrypt really thought through? Apparently it is much more invasive than expected. And should have been done in Rawhide only! (In reply to Stas Sergeev from comment #6) > No, its not fixed. > Upgraded to libxcrypt-4.4.22-1.fc35.x86_64 > > sudo now works - big relief. > user login now works - also good. > > su still doesn't work: > > Password: > You are required to change your password immediately (administrator > enforced). > Current password: > > root login still doesn't work. Have you tried to change the root password, as the system requires you at the login prompt? I've tried myself by manually setting the hash for the root password to something really ancient like md5crypt, which was commonly used until 2009. I can login with that password, and I am immediately asked to change it, which works flawlessly. BTW, you can also change your root password using sudo: `sudo passwd root` > > In a mean time, let me note that > this is the worst bug I've ever seen. > Not too many people will come for > an update: they will just lose their > system. As I already stated, one can login, change their pw and things are fine. Once the pw has been changed, one can change it back to the well-known previous one, if they prefer to. *** (In reply to Tomáš Mráz from comment #7) > Is this change in libxcrypt really thought through? Apparently it is much > more invasive than expected. And should have been done in Rawhide only! Well, the bug reporter didn't change their root pw since 2005 (see screenshot). Also the change in libxcrypt doesn't block anyone from logging in; they are simply requested to change their pw, if they still use a hash computed using descrypt and/or md5crypt. Users, who changed their pw within the last 10 years, are not affected. Also, libxcrypt v4.4.22 is still in (and will remain there for a longer period of time) updates-testing for F34 and earlier. Anyways, the logic (call to crypt_checksalt), that triggers the request to change the pw, is in PAM since a long time, it hasn't just been activated in previous versions of libxcrypt. The fact few people are now requested to change their password is basically a security consideration, as they are still using a dangerously flawed hash in the shadow file. Just for the records: Logging into the root account with an ancient pw hash from terminal and `su` works. The request to change the password comes up, and the password can be changed successfully. > Have you tried to change the root password, as the system requires you at the login prompt? I tried to specify the same password, yes. It doesn't let me do so. I haven't tried anything else because the expiration of that password is disabled, so the message is ibviously wrong. > The fact few people are now requested to change their password is basically a security consideration, > as they are still using a dangerously flawed hash in the shadow file. Thanks for an explanation, but can it be handled in a better way? Rather than preventing a login and telling people that the never expiring password have expired, how about to write a warning: "Your password uses hash XXX that is known to be vulnerable since year YYY. You should change your password to update its hash to ZZZ because it is known to be strong in year 2021.", and in case of the disabled expiration, allow the user to just type the previous password? Please note that when you see the totally absurd message, like that "you are ordered to change your password immediately, type your password now or administrator will kill you!", the first thing you think is that you've being hacked. This means, you will sure as hell NOT type your password (to a key-logger), but rather try to hack into the system by some other means. So if you want people to follow your request, please get rid of the absurd messages first. FEDORA-2021-e6916d6758 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-e6916d6758 FEDORA-2021-e6916d6758 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-e6916d6758 FEDORA-2021-fed63bd217 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-fed63bd217 FEDORA-2021-fed63bd217 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-fed63bd217 FEDORA-2021-fed63bd217 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-fed63bd217` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-fed63bd217 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2021-e6916d6758 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-e6916d6758` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-e6916d6758 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. I confirm that libxcrypt-4.4.22-2.fc35.x86_64 seems to have fixed it for me. It doesn't print a warning about an insecure hash though, which might still be good to have. Thanks for fixing this problem. FEDORA-2021-e6916d6758 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2021-fed63bd217 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. |