Description of problem: If PermitPAMUserChange is set to yes in the sshd_config for gsi-openssh-server, anyone is allowed to login to the system with existing user even if they provide incorrect password Version-Release number of selected component (if applicable): 7.9p1-3.fc29 How reproducible: Always Steps to Reproduce: 1. Install gsi-openssh-server 2. Initialize rsa, ecdsa, ed25519 keys for gsi-openssh server using gsissh-keygen 2. Set PermitPAMUserChange to yes in /etc/gsissh/sshd_config 3. Run /usr/sbin/gsisshd 4. Try to connect to the system using Putty with user "root" and some incorrect password like "test1234" (The actual password for root on the test system was root1234) Actual results: User gets logged in even though there is a failure entry in /var/log/messages for user authentication Expected results: User should not be able to login unless he provides the correct password Additional info: This use to work fine on 7.7p1. I haven't tested the 7.8p1 but its possible that earlier versions might also be vulnerable.
I have posted a request for CVE and have got the following id for the same. CVE-2019-7639
I went through the code of openssh-7.9p1-gsissh.patch I found the following code at line 511 sshpam_err = pam_authenticate(sshpam_handle, flags); + if (options.permit_pam_user_change) { + sshpam_check_userchanged(); + } and then I saw the definition of sshpam_check_userchanged() function and I noticed that its also using the same variable "sshpam_err" to check if the user that we want to map to exists. But because of that, it changes sshpam_err to say that the operation was a success. The code present on line 515 onward interpret it as authentication was successful and user ends up logging into the system with incorrect password.
gsi-openssh-7.9p1-5.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-af3d726d38
gsi-openssh-7.8p1-3.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2019-710afd062a
+ not affected - affected + gsi-openssh-7.7p1-5.fc28 - gsi-openssh-7.8p1-1.fc28 - gsi-openssh-7.8p1-2.fc28 + gsi-openssh-7.8p1-3.fc28 + gsi-openssh-7.7p1-5.fc29 - gsi-openssh-7.9p1-1.fc29 - gsi-openssh-7.9p1-2.fc29 - gsi-openssh-7.9p1-3.fc29 - gsi-openssh-7.9p1-4.fc29 + gsi-openssh-7.9p1-5.fc29 + gsi-openssh-7.7p1-5.fc30 - gsi-openssh-7.9p1-1.fc30 - gsi-openssh-7.9p1-2.fc30 - gsi-openssh-7.9p1-2.fc30.1 - gsi-openssh-7.9p1-3.fc30- - gsi-openssh-7.9p1-3.fc30.1 - gsi-openssh-7.9p1-4.fc30 + gsi-openssh-7.9p1-5.fc30
gsi-openssh-7.8p1-3.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-710afd062a
gsi-openssh-7.9p1-5.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-af3d726d38
gsi-openssh-7.8p1-3.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
gsi-openssh-7.9p1-5.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.