CVE-2018-15473 patch introduce user enumeration vulnerability

Bug #1934501 reported by Kazza
This bug affects 1 person
Affects Status Importance Assigned to Milestone
openssh (Ubuntu)
Fix Released
Marc Deslauriers

Bug Description

I was recently using a 18.04 machine and noticed that the result of connecting to ssh with an arbitrary public key varied depending if the user was valid.

After some investigation, it appears to only be present when CVE-2018-15473.patch has been applied.

Directly pulling a 18.04 docker image and installing openssh server (currently 1:7.6p1-4ubuntu0.3) results in a trivial user enumeration vulnerability in the default config.

Below shows the setup of environment:

$ docker pull ubuntu:18.04
18.04: Pulling from library/ubuntu
Digest: sha256:139b3846cee2e63de9ced83cee7023a2d95763ee2573e5b0ab6dea9dfbd4db8f
Status: Image is up to date for ubuntu:18.04
$ docker run -t -i --rm -e TERM=${TERM} ubuntu:18.04
root@75569fbf0b03:/# apt update
root@75569fbf0b03:/# apt install openssh-server
root@75569fbf0b03:/# dpkg-query -l openssh\*
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
ii openssh-client 1:7.6p1-4ubuntu0.3 amd64 secure shell (SSH) client, for secure access to remote machines
ii openssh-server 1:7.6p1-4ubuntu0.3 amd64 secure shell (SSH) server, for secure access from remote machines
ii openssh-sftp-server 1:7.6p1-4ubuntu0.3 amd64 secure shell (SSH) sftp server module, for SFTP access from remote machines
root@75569fbf0b03:/# mkdir /run/sshd
root@75569fbf0b03:/# /usr/sbin/sshd -D

Then to perform user enumeration, connecting with a public key results in user enumeration:
* in the following is removed as it slightly changes message flow
* I have not checked different versions of the ssh client

$ ssh -V
OpenSSH_8.2p1 Ubuntu-4ubuntu0.2, OpenSSL 1.1.1f 31 Mar 2020

$ ssh-keygen -t rsa -C dummy -P '' -f id_rsa-dummy
$ rm

$ ssh -i id_rsa-dummy invalid@
Connection closed by port 22

$ ssh -i id_rsa-dummy root@
root@'s password:

That is, when invalid users are provided to public key auth the connection is closed by the server. Otherwise, it will move onto the next auth method. This can be improved by adding "ssh -o PasswordAuthentication=no" when connecting to avoid password prompt and get an easy to script error message.

I have verified that this behaviour is present after starting with original source and only applying CVE-2018-15473.patch from the openssh_7.6p1-4ubuntu0.3.debian.tar.xz archive. Without this patch this behaviour is not present.

$ md5sum openssh-7.6p1.tar.gz debian/patches/CVE-2018-15473.patch
06a88699018e5fef13d4655abfed1f63 openssh-7.6p1.tar.gz
6101d47f542690b0c5e354ec8b8a70a1 debian/patches/CVE-2018-15473.patch

CVE References

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

This sounds like the following, which the upstream OpenSSH developers chose to ignore:

Could you confirm? Thanks!

Changed in openssh (Ubuntu):
status: New → Incomplete
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

That issue was assigned CVE-2018-15919

Revision history for this message
Kazza (kaz-kanso) wrote :

Thanks for the suggestion. But I believe this is a separate issue:

1. As far as I can tell, this issue is related to public key and not gssapi auth method. In the tests I made GSSAPIAuthentication was set to default (i.e. turned off).

2. I have been unable to reproduce it in vanilla OpenSSH releases. Only time I can reproduce it is after patch CVE-2018-15473.patch has been applied.

Further just to check, I have just tried with a vanilla openssh-7.8p1.tar.gz (as identified in and the issue is not present. Also, I broke CVE-2018-15473.patch up and only applied changes that it makes to auth2-pubkey.c (i.e. ignoring that changes to auth2-gss.c) and the issue was present.

Regardless, considering the age of the software and the effort required to property track this down I guess this will be marked as a WontFix issue too.

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

Thanks for the info, I'll do some tests on my end to investigate the issue.

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

I have located the issue, it is caused by a backporting error in the CVE-2018-15473 patch. I have uploaded a package for building in the security team PPA here:

Once it is finished building, could you please test the package and let us know if it also fixes the issue for you? Thanks, and thanks for reporting this!

Changed in openssh (Ubuntu):
status: Incomplete → Confirmed
assignee: nobody → Marc Deslauriers (mdeslaur)
Revision history for this message
Kazza (kaz-kanso) wrote :

Nice work, thanks Marc!

To confirm, I tested 1:7.6p1-4ubuntu0.5 from the ppa and the vulnerability was not present. Further I run a standard CVE-2018-15473 exploit script and it was unable to determine the difference between a valid and invalid user. So all appears correct from my perspective.

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

Great, thanks for testing! I'll release it tomorrow.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

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

  * SECURITY REGRESSION: User enumeration issue (LP: #1934501)
    - debian/patches/CVE-2018-15473.patch: updated to fix bad patch

 -- Marc Deslauriers <email address hidden> Wed, 11 Aug 2021 14:02:09 -0400

Changed in openssh (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

Can I make this bug public now that the update has been released?

Revision history for this message
Kazza (kaz-kanso) wrote :

Fine by me, thanks for checking.

information type: Private Security → Public Security
Revision history for this message
Pavel Malyshev (afunix) wrote (last edit ):

Hi. I believe my Ubuntu systems just received this patch and I believe it failed to install:
Can't exec "/tmp/openssh-server.config.neW0Pf": Permission denied at /usr/share/perl/5.26/IPC/ line 178.
open2: exec of /tmp/openssh-server.config.neW0Pf configure 1:7.6p1-4ubuntu0.3 failed: Permission denied at /usr/share/perl5/Debconf/ line 59.

I think this is due to the fact I have noexec on /tmp.
Is it possible to bundle the changes in the package instead of putting a random temporary file in /tmp and attempt to execute it?

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

This isn't specific to the openssh update. Debian packages use tools such as debconf that need to write to /tmp to function correctly.

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :
Revision history for this message
Utkarsh Gupta (utkarsh) wrote :

Hi Kazza, Marc,

I was wondering if you can repro the same bug in Debian Stretch? Do you have the capacity to test that as well, please? :)

Revision history for this message
Kazza (kaz-kanso) wrote :

Hello Utkarsh,

I've just quickly run through the steps in the original bug report against a recent Debian Stretch docker image and as not able to reproduce it.

Image tested:
$ docker images | grep stretch
debian stretch d74a4ce6ed8b 11 days ago 101MB

If you are concerned, I suggest looking into the history/VCS logs of:
* debian/patches/CVE-2018-15473.patch

Then you can know if it traces back to Debian.

Hope it help.

Revision history for this message
Utkarsh Gupta (utkarsh) wrote :

Thanks, Kazza. That certainly helped. I also had a word with Marc and we reached to the conclusion that Stretch isn't affected with this backporting problem.

Thanks, again! \o/

To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.