A vulnerability classified as critical has been found in gsi-openssh-server 7.9p1 on Fedora (Connectivity Software) on server (http://95.217.64.181:22

How it was found

Summary:

" hello " vulnerability: GSI-OPENSSH-SERVER 7.9P1 ON FEDORA /ETC/GSISSH/SSHD_CONFIG CREDENTIALS MANAGEMENT Description of problem: A vulnerability classified as critical has been found in gsi-openssh-server 7.9p1 on Fedora (Connectivity Software) on server (http://95.217.64.181:22). This affects some unknown functionality of the file /etc/gsissh/sshd_config. The manipulation with an unknown input leads to a privilege escalation vulnerability. CWE is classifying the issue as CWE-255. This is going to have an impact on confidentiality, integrity, and availability. The summary by CVE is:

An issue was discovered in gsi-openssh-server 7.9p1 on Fedora 29. If PermitPAMUserChange is set to yes in the /etc/gsissh/sshd_config file, logins succeed with a valid username and an incorrect password, even though a failure entry is recorded in the /var/log/messages file. The bug was discovered 02/08/2019. The weakness was released 02/08/2019. This vulnerability is uniquely identified as CVE-2019-7639 since 02/08/2019. It is possible to initiate the attack remotely. No form of authentication is needed for exploitation. Technical details of the vulnerability are known, but there is no available exploit. The attack technique deployed by this issue is T1552 according to MITRE ATT&CK.

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

How reproducible: Always

Steps to Reproduce:

1. Install gsi-openssh-server
2. Initialize rsa, ecdsa, ed25519 keys for gsi-openssh server using gsissh-keygen
3. Set PermitPAMUserChange to yes in /etc/gsissh/sshd_config
4. Run /usr/sbin/gsisshd
5. 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: its possible that earlier versions might also be vulnerable.

https://nvd.nist.gov/vuln/detail/CVE-2019-7639

Impact

This is going to have an impact on confidentiality, integrity, and availability