| Summary: | CVE-2018-15919 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | Jason Sikes <jsikes> | ||||
| Component: | Kerberos support | Assignee: | Assigned to nobody <unassigned-bugs> | ||||
| Status: | NEW --- | ||||||
| Severity: | minor | ||||||
| Priority: | P5 | ||||||
| Version: | 7.9p1 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Attachments: |
|
||||||
Created attachment 3249 [details] Patch for "user enumeration via auth2-gss.c" Hi. I created a patch for CVE-2018-15919, "user enumeration via auth2-gss.c" (even though it is not user enumeration). While this patch appears to fix the problem, at least from my small amount of testing, I can't be sure that I am not introducing a new bug or a new security hole. Hopefully some people who are more knowledgeable can take a look. The fix is two parts: 1) When a valid username is presented, sshd responds with SSH_MSG_USERAUTH_INFO_REQUEST. Otherwise, sshd responds with SSH_MSG_USERAUTH_FAILURE. My solution to this is to remove the code that presents the SSH_MSG_USERAUTH_FAILURE when an invalid username is presented. The expectation is that the login will be verified if/when the gssapi credentials are presented later. This way, the attacker will be presented with SSH_MSG_USERAUTH_INFO_REQUEST regardless of whether the user exists or not. 2) The failure count is not incremented when the username is valid. I created an interim value, was_postponed, that records the value of postponed so that when postponed is reset and the authentication is checked it can be used to determine whether the failure count can be increased. I hope that you will find this useful.