CVE-2018-15473 - User enumeration vulnerability

[Alex Tomkins]

https://nvd.nist.gov/vuln/detail/CVE-2018-15473

OpenSSH through 7.7 is prone to a user enumeration vulnerability due to not delaying bailout for an invalid authenticating user until after the packet containing the request has been fully parsed, related to auth2-gss.c, auth2-hostbased.c, and auth2-pubkey.c.

Fixed in Debian: https://www.debian.org/security/2018/dsa-4280

Currently pending triage? https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-15473.html

[Ryan Finnie (fo0bar)]

FYI, Qualys is now considering CVE-2018-15473 a PCI-DSS fail condition (QID: 38726).

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "bionic-upstream-delay-bailout-for-invalid-authenticating-user.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Ryan Finnie (fo0bar)]

All debdiffs tested in the wild (except artful).

[Christian Ehrhardt  (paelzer)]

Hi,
FYI I checked with the Security Team and this CVE seems considered low prio.
But the ubuntu-security-sponsor is subscribed so the will get to consider it.

[Launchpad Janitor (janitor)]

This bug was fixed in the package openssh - 1:6.6p1-2ubuntu2.11

---------------
openssh (1:6.6p1-2ubuntu2.11) trusty-security; urgency=medium

  * SECURITY UPDATE: OpenSSH User Enumeration Vulnerability (LP: #1794629)
    - debian/patches/CVE-2018-15473.patch: delay bailout for invalid
      authenticating user until after the packet containing the request
      has been fully parsed.
    - CVE-2018-15473
  [ Leonidas S. Barbosa ]
  * SECURITY UPDATE: Privsep process chrashing via an out-of-sequence
    - debian/patches/CVE-2016-10708.patch: fix in kex.c,
      pack.c.
    - CVE-2016-10708

 -- Ryan Finnie <email address hidden> Sat, 13 Oct 2018 23:31:08 +0000

[Launchpad Janitor (janitor)]

This bug was fixed in the package openssh - 1:7.2p2-4ubuntu2.6

---------------
openssh (1:7.2p2-4ubuntu2.6) xenial-security; urgency=medium

  [ Ryan Finnie ]
  * SECURITY UPDATE: OpenSSH User Enumeration Vulnerability (LP: #1794629)
    - debian/patches/CVE-2018-15473.patch: delay bailout for invalid
      authenticating user until after the packet containing the request
      has been fully parsed.
    - CVE-2018-15473
  * SECURITY UPDATE: Privsep process chrashing via an out-of-sequence
    - debian/patches/CVE-2016-10708.patch: fix in kex.c,
      pack.c.
    - CVE-2016-10708

 -- <email address hidden> (Leonidas S. Barbosa) Thu, 01 Nov 2018 16:16:02 -0300

[Launchpad Janitor (janitor)]

This bug was fixed in the package openssh - 1:7.6p1-4ubuntu0.1

---------------
openssh (1:7.6p1-4ubuntu0.1) bionic-security; urgency=medium

  [ Ryan Finnie ]
  * SECURITY UPDATE: OpenSSH User Enumeration Vulnerability (LP: #1794629)
    - debian/patches/CVE-2018-15473.patch: delay bailout for invalid
      authenticating user until after the packet containing the request
      has been fully parsed.
    - CVE-2018-15473

 -- <email address hidden> (Leonidas S. Barbosa) Mon, 05 Nov 2018 08:51:29 -0300

[root (mysky)]

How to get the fix installed via apt?. any link..?

[Seth Arnold (seth-arnold)]

root: sudo apt update && sudo apt upgrade

Thanks

[root (mysky)]

@seth, apt-upgrade doesnt update even in 18.04, I had to compile new ver 7.9p1 and replace the sshd bin file..!, don't know why it is still not pushed to the main repo!.

[Seth Arnold (seth-arnold)]

root, version 1:7.6p1-4ubuntu0.1 was published to the archive on November 6th 2018:

https://launchpad.net/ubuntu/+source/openssh/1:7.6p1-4ubuntu0.1
https://lists.ubuntu.com/archives/bionic-changes/2018-November/017000.html
https://usn.ubuntu.com/3809-1/

A default configuration of Ubuntu 18.04 LTS with unattended-upgrades installed would have received this update within the next 36 hours or so. If you installed before November 6th, then you probably received the update November 6th or 7th. If you installed after November 6th, then you probably received the update during installation. You can check /var/log/dpkg.log* files to find the exact date and time you received the update.

Thanks

[root (mysky)]

@Seth, if the update released after November 6th 2018, then why I am getting 7.6p1 version even when i install with the latest ISO distro from Feb 10 here ?.

http://cdimage.ubuntu.com/releases/18.04.2/release/ubuntu-18.04.2-server-amd64.iso

The above ISO is from Feb 2019 and it should be having an update of the fixed version, but it doesn't!.

[Seth Arnold (seth-arnold)]

Root, version 1:7.6p1-4ubuntu0.1 included the fix for CVE-2018-15473.

Version 1:7.6p1-4ubuntu0.2 is included in the disc image ubuntu-18.04.2-server-amd64:

$ sha256sum ubuntu-18.04.2-server-amd64.iso
a2cb36dc010d98ad9253ea5ad5a07fd6b409e3412c48f1860536970b073c98f5 ubuntu-18.04.2-server-amd64.iso
$ bsdtar tf ubuntu-18.04.2-server-amd64.iso | grep openssh
pool/main/o/openssh
pool/main/o/openssh/openssh-client-udeb_7.6p1-4ubuntu0.2_amd64.udeb
pool/main/o/openssh/openssh-client_7.6p1-4ubuntu0.2_amd64.deb
pool/main/o/openssh/openssh-server-udeb_7.6p1-4ubuntu0.2_amd64.udeb
pool/main/o/openssh/openssh-server_7.6p1-4ubuntu0.2_amd64.deb
pool/main/o/openssh/openssh-sftp-server_7.6p1-4ubuntu0.2_amd64.deb
pool/main/o/openssh/ssh_7.6p1-4ubuntu0.2_all.deb

1:7.6p1-4ubuntu0.2 includes the fix from 1:7.6p1-4ubuntu0.1 and fixes three more CVEs:
- CVE-2018-20685
- CVE-2019-6109
- CVE-2019-6111

During the install, you have the option of downloading and installing updates. These additional updates include openssh version 1:7.6p1-4ubuntu0.3 which includes addition fixes for one CVE:
- CVE-2019-6111

Thanks

[root (mysky)]

@set, That's fine, but scanned Qualys report suggests to install openssh >7.8 to fix this bug!, not sure where is the issue, PFA for sample qualys report, do you know how to change the openssh version and hide OS version without compiling?, any SSHD_options? let me know.

Thanks

[Vital Koshalew (vital-0)]

@root (mysky),

Qualys is slow to fix their detection algorithm. You just need to provide them with False Positive report citing the vendor documentation (https://usn.ubuntu.com/3809-1/).
Faking software version is the last thing someone should do to be PCI DSS compliant.

[Seth Arnold (seth-arnold)]

Root, aha! We've finally uncovered the root of the problem. (Sorry. I can't help myself. It's Friday afternoon.)

While Qualys' TLS scanner is a top-notch tool that I use regularly, their "security scanner" is sadly not. They have built a tool that checks version numbers. This is not ideal, because the clear majority of Linux systems do not do wholesale version updates but instead backport specific security fixes:

https://wiki.ubuntu.com/SecurityTeam/FAQ#Versions
https://www.debian.org/security/faq#version
https://wiki.centos.org/FAQ/General#head-3dad8cb98ac535185e58e882a23ca4b096cbff2f
https://access.redhat.com/security/updates/backporting

These sorts of security scanners would be more useful if everyone built their entire systems from scratch.

Anyway, please ask Qualys to consider consuming our OVAL data:
https://people.canonical.com/~ubuntu-security/oval/
or parsing our database directly:
https://git.launchpad.net/ubuntu-cve-tracker

Both of these approaches would give better results. (There are tradeoffs involved. They are welcome to contact us at <email address hidden> if they would like to discuss the tradeoffs.)

Thanks

[root (mysky)]

@Vital & Seth
Thanks for the clarification, so qualys is the culprit!, such a good security company providing false reports without actually doing full scan, and now I am looking for a script to demonstrate this vulnerability fix, any good script?

  Will this do..?
 https://github.com/nccgroup/ssh_user_enum

[Vital Koshalew (vital-0)]

@root (mysky),

You don't need any scripts. Referring to a vendor's documentation (https://usn.ubuntu.com/3809-1/ in this case) is usually enough.

See also: https://pci.qualys.com/static/help/merchant/false_positives/submit_false_positive_requests.htm

[Vital Koshalew (vital-0)]

@Seth Arnold,

Qualys automated vulnerability scanner is not supposed to do any penetration testing, including vulnerability exploitation attempts as it is ran unattended so must not create any risks of DoS. Trying to exploit some vulnerabilities can jeopardize production systems. This way, such non-intrusive scans are by definition limited to sending completely legitimate requests, checking the responses and then analyzing them based on a vulnerability database.

[Seth Arnold (seth-arnold)]

Root, that script is suitable for timing attacks against ssh. This issue is easier to use to enumerate users, but does require a different approach. There was a tool posted to oss-security for this: https://www.openwall.com/lists/oss-security/2018/08/16/1

Thanks

[Seth Arnold (seth-arnold)]

Vital, just scanning version banners is what leads to this problem. Inspecting the package database would be far more reliable.

Thanks

[Vital Koshalew (vital-0)]

@seth-arnold,

You are talking about a different type of vulnerability scanning that is not part of the Qualys service in question (External vulnerability scan, "black box" scan methodology). PCI DSS also mandates regular internal scans and penetration tests. Qualys, as well as other vendors provides such services.

As for determining package version directly vs. by version banner, I don't see any difference *in this case* as by default full ubuntu-specific package version is displayed in SSH version banner and Qualys requires users not to interfere with the scanning.

The issue that @root(mysky) has stems from the fact that Qualys is usually very fast when including a vulnerable product in their detector but sometimes slow to exclude fixed versions as in this case. This isn't a big deal as they have False Positive Report mechanism that allows a live service representative to asses the situation and allow your system to pass even if the automatic scanner detects a non-existent vulnerability.