touch-packages team mailing list archive

[Ethan Rahn <ethan.rahn@xxxxxxxxx>]

Public bug reported:

When testing a fix for CVE-2015-5600 based on the Ubuntu patch in
openssh-5.9 (
https://launchpadlibrarian.net/214490716/openssh_1%3A5.9p1-5ubuntu1.4_1%3A5.9p1-5ubuntu1.6.diff.gz
), I noticed that there was an issue with getting permission denied when
trying to log in lots of times with what should be valid credentials.

The symptom was when logging in with the command and sshd_config below I
would get permission denied sometimes and permission granted other
times. Upon investigating the reason for permission being denied was
sshd erroneously thinking "pam" had already been used as a login method
on the first attempt to use it. This appeared to be related to the
kbdinit_alloc function in auth2_chall.c not initializing devices_done.
Once I made the following patch the issue went away:

@@ -130,6 +131,7 @@ kbdint_alloc(const char *devs)
        kbdintctxt->ctxt = NULL;
        kbdintctxt->device = NULL;
        kbdintctxt->nreq = 0;
+       kbdintctxt->devices_done = 0;

        return kbdintctxt;
 }

Since openssh uses xmalloc ( i.e. malloc or die ) to initialize data
structures, it seems that the issue is the struct not getting zero'ed
out at the start. I haven't taken the time to verify this in openssh-6.9
/ openssh-7.0, but it seems like since xmalloc / malloc is still in use
that it should still fail in the same manner.

These are the ssh command sshd_config that were in use when the issue was happening. I'm not sure if something about them makes the issue more likely to happen:
===
ssh command: 
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=120 -o ServerAliveInterval=15 -m hmac-md5 -c aes256-ctr -e \~ -oKexAlgorithms=diffie-hellman-group-exchange-sha1 <username>@<host>


sshd_config:
Protocol 2
Port 22
SyslogFacility AUTHPRIV
PasswordAuthentication no
ChallengeResponseAuthentication yes
UsePAM yes
MaxStartups 10:30:100
Subsystem sftp /usr/libexec/openssh/sftp-server
PermitEmptyPasswords yes
AllowTcpForwarding no
Banner /etc/issue
StrictModes yes
UsePrivilegeSeparation yes
Compression delayed
GatewayPorts no
GSSAPIAuthentication no
KerberosAuthentication no
LoginGraceTime 120
LogLevel DEBUG2
Ciphers 3des-cbc,aes128-cbc,aes128-ctr,aes192-cbc,aes192-ctr,aes256-cbc,aes256-ctr,arcfour,arcfour128,arcfour256,blowfish-cbc,cast128-cbc
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
MACs hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96
HostKey <removed rsa keypath>
HostKey <removed dsa keypath>

===

Is anyone else able to see this issue and verify that my fix is correct?

Thanks,

Ethan

** Affects: openssh (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1485807

Title:
  Fix for CVE-2015-5600 can sometimes erroneously block logins

Status in openssh package in Ubuntu:
  New

Bug description:
  When testing a fix for CVE-2015-5600 based on the Ubuntu patch in
  openssh-5.9 (
  https://launchpadlibrarian.net/214490716/openssh_1%3A5.9p1-5ubuntu1.4_1%3A5.9p1-5ubuntu1.6.diff.gz
  ), I noticed that there was an issue with getting permission denied
  when trying to log in lots of times with what should be valid
  credentials.

  The symptom was when logging in with the command and sshd_config below
  I would get permission denied sometimes and permission granted other
  times. Upon investigating the reason for permission being denied was
  sshd erroneously thinking "pam" had already been used as a login
  method on the first attempt to use it. This appeared to be related to
  the kbdinit_alloc function in auth2_chall.c not initializing
  devices_done. Once I made the following patch the issue went away:

  @@ -130,6 +131,7 @@ kbdint_alloc(const char *devs)
          kbdintctxt->ctxt = NULL;
          kbdintctxt->device = NULL;
          kbdintctxt->nreq = 0;
  +       kbdintctxt->devices_done = 0;

          return kbdintctxt;
   }

  Since openssh uses xmalloc ( i.e. malloc or die ) to initialize data
  structures, it seems that the issue is the struct not getting zero'ed
  out at the start. I haven't taken the time to verify this in
  openssh-6.9 / openssh-7.0, but it seems like since xmalloc / malloc is
  still in use that it should still fail in the same manner.

  These are the ssh command sshd_config that were in use when the issue was happening. I'm not sure if something about them makes the issue more likely to happen:
  ===
  ssh command: 
  ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=120 -o ServerAliveInterval=15 -m hmac-md5 -c aes256-ctr -e \~ -oKexAlgorithms=diffie-hellman-group-exchange-sha1 <username>@<host>

  
  sshd_config:
  Protocol 2
  Port 22
  SyslogFacility AUTHPRIV
  PasswordAuthentication no
  ChallengeResponseAuthentication yes
  UsePAM yes
  MaxStartups 10:30:100
  Subsystem sftp /usr/libexec/openssh/sftp-server
  PermitEmptyPasswords yes
  AllowTcpForwarding no
  Banner /etc/issue
  StrictModes yes
  UsePrivilegeSeparation yes
  Compression delayed
  GatewayPorts no
  GSSAPIAuthentication no
  KerberosAuthentication no
  LoginGraceTime 120
  LogLevel DEBUG2
  Ciphers 3des-cbc,aes128-cbc,aes128-ctr,aes192-cbc,aes192-ctr,aes256-cbc,aes256-ctr,arcfour,arcfour128,arcfour256,blowfish-cbc,cast128-cbc
  KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
  MACs hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96
  HostKey <removed rsa keypath>
  HostKey <removed dsa keypath>

  ===

  Is anyone else able to see this issue and verify that my fix is
  correct?

  Thanks,

  Ethan

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1485807/+subscriptions