Bug 2975 - CVE-2018-15919
Summary: CVE-2018-15919
Status: NEW
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: Kerberos support (show other bugs)
Version: 7.9p1
Hardware: All All
: P5 minor
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-03-05 11:03 AEDT by Jason Sikes
Modified: 2019-03-05 11:03 AEDT (History)
0 users

See Also:


Attachments
Patch for "user enumeration via auth2-gss.c" (1.47 KB, patch)
2019-03-05 11:03 AEDT, Jason Sikes
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jason Sikes 2019-03-05 11:03:28 AEDT
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.