Passwords longer than 255 characters break authentication

Bug #1822736 reported by Tom Reynolds
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
pam (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

DISCUSSION

When a password longer than 255 characters is set for any user account, this user will become unable to authenticate when running 'sudo' or 'passwd'.

IMPACT

This affects 18.04.2 systems, whether they were installed using Desktop (ubiquity) or Server (subiquity) installers. It may also affect other releases - this is yet untested.

Tagged 'security' since these utilities then deny service to this user.

REPRODUCTION

# Add user 'test' with password 'testtest'
sudo adduser --gecos '' test

# Add user 'test' to the 'sudo' group
sudo adduser test sudo

# Become user 'test'
sudo -iu test

# Verify user 'test' can run commands via sudo
sudo whoami

# Change password of 'test' to this 255 character long password: 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345
passwd

# Verify user 'test' can run commands via sudo with the new password set
sudo -k
sudo whoami # should report "root"

# Change password of 'test' to 'testtest':
passwd

# Verify user 'test' can run commands via sudo with the new password set
sudo -k
sudo whoami # should report "root"

# Change password of 'test' to this 256 character long password: 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
passwd

# Verify user 'test' can run commands via sudo with the new password set
sudo -k
sudo whoami # should report "root"

# This authentication fails, as sudo does not accept the 256 character password.
# Attempting to change this password to a different value also fails:
passwd

# Effectively, user 'test' is now unable to use sudo, or to change their password.

# The 'login' command, run by root, does, however, still enable user 'test' to login using the newly set 256 character password.
# At the same time, a different restricted user who is a member of the 'sudo' group can still set a new password for 'test' (after authenticating to sudo with their own password) by supplying the current 256 character password using:
sudo -u test passwd

# Finally, to clean up
sudo deluser --remove-home test

ADDITIONAL OBSERVATIONS

* A root-initiated 'login' command still allows this user to authenticate.
* A different restricted user who is a member of the 'sudo' group can still set a new password for for this users' account (after authenticating to sudo with their own password) by supplying the >=256 character password

CREDIT

This was originally reported by 'Fieldy', I just reproduced it / filed this bug report.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: libpam0g 1.1.8-3.6ubuntu2.18.04.1
ProcVersionSignature: Ubuntu 4.18.0-16.17~18.04.1-generic 4.18.20
Uname: Linux 4.18.0-16-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.6
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Apr 2 09:39:39 2019
SourcePackage: pam
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Tom Reynolds (tomreyn) wrote :
Tom Reynolds (tomreyn)
description: updated
description: updated
Revision history for this message
Tom Reynolds (tomreyn) wrote :

This also affects Fedora 29 (Workstation).

Alex Murray (alexmurray)
information type: Private Security → Public Security
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in pam (Ubuntu):
status: New → Confirmed
Revision history for this message
Chris Guiver (guiverc) wrote :

I followed Tom's REPRODUCTION test, and got exactly what Tom said I would.
I can confirm the issue with 256 character passwords.
(I used `wc` to count characters in my buffer)

I could set the 256 character password (I used it with a backspace to enter the old password, so it was only 1 character longer) but it wouldn't then let me use it for the next `sudo whoami`.

x86 Lubuntu 19.04 (fully-updated) box

OS: Ubuntu Disco Dingo (development branch) i686
Host: HP Compaq dx6120 MT(PL926AV)
Kernel: 5.0.0-8-generic
Uptime: 14 mins
Packages: 1968 (dpkg)
Shell: bash 5.0.2
Theme: Arc-Darker [GTK3]
Icons: Adwaita [GTK3]
Terminal: qterminal
CPU: Intel Pentium 4 2.80GHz (2) @ 2.790GHz
GPU: NVIDIA GeForce 7600 GT
Memory: 487MiB / 2953MiB

test@dx6120-lubu:~$ apt-cache policy libpam0g
libpam0g:
  Installed: 1.3.1-5ubuntu1
  Candidate: 1.3.1-5ubuntu1
  Version table:
 *** 1.3.1-5ubuntu1 500
        500 http://ftp.iinet.net.au/pub/ubuntu disco/main i386 Packages
        100 /var/lib/dpkg/status

Revision history for this message
Chris Guiver (guiverc) wrote :

Booted up a Ubuntu 14.04 LTS box & followed test procedure.

Same result - steps followed fine until I once 256 char password was entered, I was unable to `sudo whoami` (password was not accepted)

OS: Ubuntu 14.04.6 LTS x86_64
Host: HP Compaq dc7700 Small Form Factor
Kernel: 3.13.0-168-generic
Uptime: 22 mins
Packages: 2377 (dpkg)
Shell: bash 4.3.11
Theme: Ambiant-MATE [GTK3]
Icons: Ambiant-MATE [GTK3]
Terminal: gnome-terminal
CPU: Intel Core 2 6320 (2) @ 1.867GHz
GPU: NVIDIA Quadro NVS 290
Memory: 1071MiB / 4896MiB

test@dc7700ub:~$ apt-cache policy libpam0g
libpam0g:
  Installed: 1.1.8-1ubuntu2.2
  Candidate: 1.1.8-1ubuntu2.2
  Version table:
 *** 1.1.8-1ubuntu2.2 0
        500 http://ftp.iinet.net.au/pub/ubuntu/ trusty-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
        100 /var/lib/dpkg/status
     1.1.8-1ubuntu2 0
        500 http://ftp.iinet.net.au/pub/ubuntu/ trusty/main amd64 Packages

Revision history for this message
Tom Reynolds (tomreyn) wrote :

It is yet unclear what the root cause of this issue is - libpam, crypt, passwd and sudo seem like primary suspects. The 256 character password is hashed to a value which still allows a TTY login to succeed. Also, passwd run by a different user in the context of the affected user (using sudo) still works. So apparently it only breaks for the logged-in user. This may help identify the root cause.

pam_unix(8) (on bionic) states:
  The maximum length of a password supported by the pam_unix module via the
  helper binary is PAM_MAX_RESP_SIZE - currently 512 bytes. The rest of the
  password provided by the conversation function to the module will be
  ignored.

Regarding passwd, I was told this on IRC:
  passwd uses getpass() to read the password from the user, and testing just
  getpass() alone shows it will return up to 4095 bytes long (i.e. truncates
  at that length).

Revision history for this message
Marc Deslauriers (mdeslaur) wrote : Bug is not a security issue

Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

information type: Public Security → Public
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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