Bug 264781
| Summary: | SSH allows attacker to divine user password | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | George Toft <george> |
| Component: | openssh | Assignee: | Tomas Mraz <tmraz> |
| Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.4 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-08-29 20:21:28 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I don't think this problem is serious enough to warrant invasive changes which would be necessary to fix this. The password should be good enough so the attacker cannot brute force it regardless whether the account is expired or not. Note that the password authentication and account/password expiration checks are done in different calls to PAM library and it wouldn't be easy to merge them into one. |
With an expired user account, an attempt to log in remotely with the wrong password results in a 3 second delay followed by: Access denied. If the correct password is entered, there is no delay before presenting the message: Access denied. An attacker could measure the time between rejections with an attack tool and determine the user's password. Version-Release number of selected component (if applicable): 3.9p1 8.RHEL4.15 How reproducible: Always Steps to Reproduce: 1. From remote machine, attempt remote login to server with an expired account. Alternately, ssh localhost. 2. Enter bogus password - view error after 3 seconds. 3. Enter correct password - view error immediately with no delay. Actual Results: no delay presented when correct password is entered Expected Results: 3 second delay before presenting "Access denied." Additional info: May be related to bug 141642 and 146882 Supporting log entries: /var/log/messages Aug 29 12:02:11 dbabb3 sshd(pam_unix)[3005]: account gtoft has expired (failed to change password) /var/log/secure Aug 29 19:20:57 dbabb3 sshd[4677]: Failed password for gtoft from ::ffff:192.168.114.1 port 3440 ssh2 Aug 29 12:20:57 dbabb3 sshd[4597]: Failed password for gtoft from ::ffff:192.168.114.1 port 3440 ssh2 Aug 29 19:20:59 dbabb3 sshd[4677]: Failed password for gtoft from ::ffff:192.168.114.1 port 3440 ssh2 Aug 29 12:20:59 dbabb3 sshd[4597]: Failed password for gtoft from ::ffff:192.168.114.1 port 3440 ssh2 Note: 1. Timing in above shows less than 3 seconds elapse between password entries 2. There are 2 different times for the same event, 7 hours apart (system is in GMT-7 America/Phoenix timezone) User entry from /etc/shadow (password hash mangled): gtoft:$1$jvmsof8HIN60h28HX$1/9YkyzdSxbe.:13615:7:90:28:7::