SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   Application (VPN)  >   OpenSSH Vendors:   OpenSSH.org
OpenSSH Authentication Attempt Processing Lets Remote Users Determine Valid Usernames on the Target System
SecurityTracker Alert ID:  1041487
SecurityTracker URL:  http://securitytracker.com/id/1041487
CVE Reference:   CVE-2018-15473   (Links to External Site)
Updated:  Aug 17 2018
Original Entry Date:  Aug 15 2018
Impact:   Disclosure of system information
Fix Available:  Yes  Vendor Confirmed:  Yes  

Description:   A vulnerability was reported in OpenSSH. A remote user can determine valid usernames on the target system.

The system responds differently to valid and invalid authentication attempts. A remote user can send specially crafted requests to determine valid usernames on the target system.

Impact:   A remote user can determine valid usernames on the target system.
Solution:   The vendor has issued a source code fix, available at:

https://github.com/openbsd/src/commit/779974d35b4859c07bc3cb8a12c74b43b0a7d1e0

Vendor URL:  openssh.org/ (Links to External Site)
Cause:   Access control error
Underlying OS:  Linux (Any), UNIX (Any), Windows (Any)

Message History:   This archive entry has one or more follow-up message(s) listed below.
Oct 24 2018 (IBM Issues Fix for IBM AIX) OpenSSH Authentication Attempt Processing Lets Remote Users Determine Valid Usernames on the Target System
IBM has issued a fix for IBM AIX 5.3, 6.1, 7.1, and 7.2.
Nov 7 2018 (Ubuntu Issues Fix) OpenSSH Authentication Attempt Processing Lets Remote Users Determine Valid Usernames on the Target System
Ubuntu has issued a fix for Ubuntu Linux 14.04 LTS, 16.04 LTS, and 18.04 LTS.



 Source Message Contents

Subject:  [oss-security] OpenSSH Username Enumeration

Hi all,

We sent the following email to openssh@openssh.com and
distros@vs.openwall.org about an hour ago, and it was decided that we
should send it to oss-security@lists.openwall.com right away (as far as
we know, no CVE has been assigned to this issue yet):

========================================================================

While reviewing the latest OpenSSH commits, we stumbled across:

https://github.com/openbsd/src/commit/779974d35b4859c07bc3cb8a12c74b43b0a7d1e0

Date:   Tue Jul 31 03:10:27 2018 +0000
    delay bailout for invalid authenticating user until after the packet
    containing the request has been fully parsed. Reported by Dariusz Tytko
    and Michal Sajdak; ok deraadt

We realized that without this patch, a remote attacker can easily test
whether a certain user exists or not (username enumeration) on a target
OpenSSH server:

  87 static int
  88 userauth_pubkey(struct ssh *ssh)
  89 {
 ...
 101         if (!authctxt->valid) {
 102                 debug2("%s: disabled because of invalid user", __func__);
 103                 return 0;
 104         }
 105         if ((r = sshpkt_get_u8(ssh, &have_sig)) != 0 ||
 106             (r = sshpkt_get_cstring(ssh, &pkalg, NULL)) != 0 ||
 107             (r = sshpkt_get_string(ssh, &pkblob, &blen)) != 0)
 108                 fatal("%s: parse request failed: %s", __func__, ssh_err(r));

The attacker can try to authenticate a user with a malformed packet (for
example, a truncated packet), and:

- if the user is invalid (it does not exist), then userauth_pubkey()
  returns immediately, and the server sends an SSH2_MSG_USERAUTH_FAILURE
  to the attacker;

- if the user is valid (it exists), then sshpkt_get_u8() fails, and the
  server calls fatal() and closes its connection to the attacker.

We believe that this issue warrants a CVE; it affects all operating
systems, all OpenSSH versions (we went back as far as OpenSSH 2.3.0,
released in November 2000), and is easier to exploit than previous
OpenSSH username enumerations (which were all timing attacks):

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0190
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5229
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6210

We also believe that this should be posted to oss-security right away:
the issue (commit) is already public, and if we spotted it, then others
(not so well intentioned) did too. We are at your disposal for
questions, comments, and further discussions.

Thank you very much! With best regards,

-- 
the Qualys Security Advisory team
 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2019, SecurityGlobal.net LLC