yppasswd results in a segmentation fault when run on clients or server

[James C. West]

[Impact]

 * The bug is a segfault on yppasswd rendering users unable to change their passwords
 * justification for the SRU is the continued request by users and the fact that it is a very minimal change
 * the fix ensures that a lib accessing data unconditionally only gets called if the values are properly initialized

[Test Case]
 * install nis
 * Config in /etc/default/nis: NISSERVER=master
 * Config in /etc/yp.conf: ypserver 127.0.0.1
 * Initialize with
     $ sudo /usr/lib/yp/ypinit -m
     $ restart rpcbind
 * Test if your config works
     $ ypcat passwd
     should show something like
     ubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash
 * Trigger the bug
     $ yppasswd -p ubuntu
     Changing NIS account information for ubuntu on wily.localdomain.
     Please enter root password:
     Changing NIS password for ubuntu on wily.localdomain.
     Please enter new password:
     Segmentation fault (core dumped)

[Regression Potential]

 * While it is assumed to not regress, if it does it is affected to break yppasswd even more (and while more than a segfault is hard to imagine I mean it might even break for those people that today got around it by some complex and weird workarounds.)
 * The code is only local to the tool yppasswd and it is not part of a lib or so, so the impact - if any - should stay local

[Other Info]
 * I really would like to encourage the users reporting it being important to them testing it once in proposed to have more than just my tests.

Sample output from a client (output is identical if run on the server):

$ yppasswd
Changing NIS account information for <user> on <server>.
Please enter old password:
Changing NIS password for <user> on <server>.
Please enter new password:
Segmentation fault (core dumped)
$

This setup worked fine with the 12.04 LTS release. I've purged package nis a number of times and reinstalled and still get the same behavior. I've also removed a slave server from the network and reconfigured nis and still get the same behavior.

I thought about listing this as a security vulnerability since the users cannot change their passwords.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: nis 3.17-32ubuntu5
ProcVersionSignature: Ubuntu 3.8.0-26.38-generic 3.8.13.2
Uname: Linux 3.8.0-26-generic x86_64
ApportVersion: 2.9.2-0ubuntu8.1
Architecture: amd64
Date: Wed Jul 24 09:07:09 2013
InstallationDate: Installed on 2010-05-24 (1156 days ago)
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
MarkForUpload: True
SourcePackage: nis
UpgradeStatus: Upgraded to raring on 2013-05-19 (65 days ago)

[James C. West (jcwest16)]

I should add, I've purged and reinstalled/reconfigured package "nis" on both the server(s) and clients a number of times but still get the same behavior.

[Launchpad Janitor (janitor)]

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

[Frank J (fjones36)]

I have the same problem.

Fresh install of Ubuntu 13.04 64bit.

NIS is installed, ypcat passwd returns proper passwd file.
I can log in as nis users, and all files and permissions are fine.
yppasswd results in Segmentation fault (core dumped) after entering new password as stated above.

[Zoli (janosizoli)]

I have the same problem on 13.10 64-bit.
yppasswd results in segfault after new password

[Jason van Dyk (jfvandyk78)]

This is also a problem in Ubuntu 12.04.3 LTS as well, at least with the current updates as of 03 Dec 13.

James, you said this worked in Ubuntu 12.0.4 LTS, was that with the most current updates?

[James C. West (jcwest16)]

It was whatever was available in July. I installed two XUbuntu 12.04.? LTS systems under VirtualBbx and confirmed then that it worked before making the bug report. I also updated both virtual systems through 12.10 and 13.04. As I recall, the problem began when the client system was updated to 13.04. (Wish I had posted the results of that experiment.)

For the record, I have the same problem with Saucy 13.10.

[James C. West (jcwest16)]

A quick additional thought...I may have started with the original release of 12.04 LTS from a disk I made in April 2012 and not made any updates before I did the VirtualBox experiment. I may try the same thing again today if I have time.

[James C. West (jcwest16)]

As I looked back at everything I did before I see that I had tested the updates in Virtualbox using the 32 bit Xubuntu releases. For the 32 bit releases the segmentation violation began when I updated the client from 12.10 to 13.04. I reran the same experiment in virtualbox last night and still got the same behavior with the 32 bit releases: current release of 12.04 LTS on the server works, 12.10 works, 13.04 fails.

I have an older CD burned that I labeled Xubuntu 64 bit 12.04.1 LTS available. I'll try the same experiment starting with that one when I get some time to get a 64 bit virtualbox running on my current platform.

[Philip (k-philip)]

I have the same problem on a fresh install of the new Ubuntu 14.04 LTS.

[Philip (k-philip)]

Just found this. Maybe, it's the same issue/related? At least I could make the segfault go away by NOT using shadow.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721737

[Gabriel Devenyi (ace-staticwave)]

I just installed a new set of workstations at my facility and now no-one can change their passwords because of this bug, is anyone going to fix this? Isn't 14.04 a long term support release?

[James C. West (jcwest16)]

I checked the link that Philip gave and the patch at the beginning worked for 14.04 when I recompiled the nis package from source. My users can finally change their passwords! The patch is

--- nis-3.17.orig/yp-tools-2.9/src/yppasswd.c 2013-09-03 12:08:35.000000000 -0400
+++ ./yppasswd.c 2013-09-03 12:07:30.000000000 -0400
@@ -406,7 +406,7 @@
       return 0;
     }

- if (pwd->pw_passwd[0]
+ if (pwd->pw_passwd[0] && pwd->pw_passwd[1]
       && !strncmp (pwd->pw_passwd, crypt (pwdstr, pwd->pw_passwd), 13)
       && uid)
     {

Can this be added to the Trusty release?

[AG (alf-gerisch)]

We have the same problem on our Ubuntu 14.04 installations (100 users and no-one can change password; that is a security issue). We do not intend to patch such basic packages like nis ourselves - at least I thought we would not need to because we run Ubuntu LTS. As a temporary workaround we have installed an old Ubuntu 12.04 machine.

[Qball Cow (qball-qballcow)]

How can a bug like this after almost 2 years not be fixed!

[Gabriel Devenyi (ace-staticwave)]

Looking at the packages in debian, looks like we're two versions behind, -32 in all ubuntu versions vs -33 in jessie and -34 in sid

[ChristianEhrhardt (paelzer)]

FYI - the merge itself would be complete, but while testing I found an issue introduced in some former ubuntu delta that would now kill the configuration of an already installed nis on update (bad handling of conffiles).
We will have to create a fix for this transition before we can go on with this.

[Launchpad Janitor (janitor)]

This bug was fixed in the package nis - 3.17-34ubuntu3

---------------
nis (3.17-34ubuntu3) xenial; urgency=medium

  [ Robie Basak ]
  * Re-merge from Debian 3.17-34 due to TIL lock confusion; verified
    with pitti and cpaelzer. This merge more comprehensively eliminates
    Ubuntu delta no longer required and fixes an upgrade path issue.

  [ Christian Ehrhardt ]
  * Merge from Debian, which includes the fix for LP: #1204530.
    Remaining changes:
    - ypbind-mt-1.20.1/src/Makefile.am: (Closes: #631628)
      put libraries in ypbind_LDADD instead of AM_LDFLAGS to fix FTBFS
      with ld --as-needed. Patch submitted to Debian but not yet
      applied.
  * Drop changes:
    - Use dh-autoreconf to fix FTBFS on arm64: adopted in Debian.
    - Convert to native upstart jobs: no longer necessary to carry in an
      Ubuntu delta as we use systemd now.
    - No longer needed as we are no longer carrying the upstart delta:
      + debhelper based dh_installdeb.
      + Revert our dropping of the init.d script.
  * Drop upstart conffiles no longer shipped (/etc/init/*) using
    dpkg-maintscript-helper rm_conffile.
  * Workaround in d/[preinst|postinst] to fix a conffile clobbering issue when
    upgrading. This was introduced in the former upstart delta but is only
    triggering now that we drop it.
  * Define d/compat compatibility level for dh-autoreconf in newer build
    environments.

 -- Christian Ehrhardt <email address hidden> Thu, 05 Nov 2015 10:48:19 +0000

[Gabriel Devenyi (ace-staticwave)]

What about trusty?

[vnq srl (info-t3)]

what about Wily Werewolf?

[vnq srl (info-t3)]

"This bug was fixed in the package nis - 3.17-34ubuntu3"

510 mirko@soppalco[12:41:19]:~$ dpkg -l nis
+++-==============-============-============-=================================
ii nis 3.17-32ubunt amd64 clients and daemons for the Netwo

511 mirko@soppalco[12:42:19]:~$ sudo apt-get upgrade nis
... nis is already upgraded

[ChristianEhrhardt (paelzer)]

First of all thanks for checking the fix. and yes so far it is only released for Xenial (16.04).

Given the time it was open and the amount of feedback we have got I assumed it wouldn't be worth an SRU - https://wiki.ubuntu.com/StableReleaseUpdates.

I'm still not sure if it is worth an SRU given the diminished adoption of yp* in the field.
However, I'm not sure this bug would qualify under that policy, although I am not on the SRU team and cannot make that decision.

I think it might be for trusty given the remaining 3 years of support.
I don't tihnk it has chances for wily.
If this is very important to you and upgrading to the upcoming LTS is no option for you do you think you could follow https://wiki.ubuntu.com/StableReleaseUpdates#Procedure for the paperwork.
Most of that is already done (for Xenial) in the bug, so I'd just ask you to discuss it with the SRU team to buy into your need.

And if the SRU team in general agrees I could prepare the upload for the final review by the SRU Team.

[ChristianEhrhardt (paelzer)]

I looked into it more in detail - It is actually a bigger change than just reusing what we did for Xenial.
Since for Xenial we did a lot of cleanup regarding upstart we can't just "reuse" what we have for trusty.

[Micha Ober (5e-hb5ntu-we)]

So, will this bug be fixed for trusty? Has any decision been made yet?

[Gabriel Devenyi (ace-staticwave)]

Running a 200+ user NIS system on Trusty, would love a fix here.

[AG (alf-gerisch)]

Same here: 100+ users relying on NIS on Trusty. Fix would be highly appreciated.

[ChristianEhrhardt (paelzer)]

Hi,
I realized that bug seems dormant :-/
So I wanted to let you know that I keep this unread in my inbox all the
time.
It juts currently buried under other priorities.

But I really intend to take a closer look at a potential SRU as soon as I
can.

Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

On Mon, Feb 1, 2016 at 7:53 PM, AG <email address hidden> wrote:

> Same here: 100+ users relying on NIS on Trusty. Fix would be highly
> appreciated.
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1204530
>
> Title:
> yppasswd results in a segmentation fault when run on clients or server
>
> Status in nis package in Ubuntu:
> Fix Released
> Status in nis package in Debian:
> Fix Released
>
> Bug description:
> Sample output from a client (output is identical if run on the
> server):
>
> $ yppasswd
> Changing NIS account information for <user> on <server>.
> Please enter old password:
> Changing NIS password for <user> on <server>.
> Please enter new password:
> Segmentation fault (core dumped)
> $
>
>
> This setup worked fine with the 12.04 LTS release. I've purged package
> nis a number of times and reinstalled and still get the same behavior. I've
> also removed a slave server from the network and reconfigured nis and still
> get the same behavior.
>
> I thought about listing this as a security vulnerability since the
> users cannot change their passwords.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 13.04
> Package: nis 3.17-32ubuntu5
> ProcVersionSignature: Ubuntu 3.8.0-26.38-generic 3.8.13.2
> Uname: Linux 3.8.0-26-generic x86_64
> ApportVersion: 2.9.2-0ubuntu8.1
> Architecture: amd64
> Date: Wed Jul 24 09:07:09 2013
> InstallationDate: Installed on 2010-05-24 (1156 days ago)
> InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64
> (20100429)
> MarkForUpload: True
> SourcePackage: nis
> UpgradeStatus: Upgraded to raring on 2013-05-19 (65 days ago)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/nis/+bug/1204530/+subscriptions
>

[ChristianEhrhardt (paelzer)]

Ok, I did the backport.
This package is somewhat scary old at some places (no patches, dh compatibility level 1 - well undefined).

Yet I was able to keep changes minimal and the changes that went into the Debian upgrade from .33 to .34 applied as is.

It is building fine in trusty.

I revived my old testbed and confirmed that the fix is really fixing the issue.
With the fix it was working cleanly changing the PW back and forth where it formerly segfaulted as reported in this bug.

[ChristianEhrhardt (paelzer)]

[Impact]

 * The bug is a segfault on yppasswd rendering users unable to change their passwords
 * justification for the SRU is the continued request by users and the fact that it is a very minimal change
 * the fix ensures that a lib accessing data unconditionally only gets called if the values are properly initialized

[Test Case]
 * install nis
 * Config in /etc/default/nis: NISSERVER=master
 * Config in /etc/yp.conf: ypserver 127.0.0.1
 * Initialize with
     $ sudo /usr/lib/yp/ypinit -m
     $ restart rpcbind
 * Test if your config works
     $ ypcat passwd
     should show something like
     ubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash
 * Trigger the bug
     $ yppasswd -p ubuntu
     Changing NIS account information for ubuntu on wily.localdomain.
     Please enter root password:
     Changing NIS password for ubuntu on wily.localdomain.
     Please enter new password:
     Segmentation fault (core dumped)

[Regression Potential]

 * While it is assumed to not regress, if it does it is affected to break yppasswd even more (and while more than a segfault is hard to imagine I mean it might even break for those people that today got around it by some complex and weird workarounds.)
 * The code is only local to the tool yppasswd and it is not part of a lib or so, so the impact - if any - should stay local

[Other Info]

 * I really want to encourage the users reporting it being important to them testing it once in proposed to have more than just my tests.
 * I wanted to nominate to be able to keep tracking Wily as Fix Released and Trusty as pending but that doesn't seem to work.
It would be great if the Sponsor with the proper permissions could also set the proper "Affects" status for those two releases

[ChristianEhrhardt (paelzer)]

Subscribing the ~ubuntu-sru Team to evaluate and consider this for a Trusty SRU.

[ChristianEhrhardt (paelzer)]

Attached proper SRU versioned debdiff and subscribing sponsors

[Robie Basak (racb)]

Uploaded. Thanks!

[Chris J Arges (arges)]

Hello James, or anyone else affected,

Accepted nis into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/nis/3.17-32ubuntu6.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[ChristianEhrhardt (paelzer)]

As there was no activity after a week I decided to do the verification on my own to unblock the transition.
Followed the listed Test Case steps, triggered the issue, enabled and updated from proposed - issue fixed.

[Martin Pitt (pitti)]

The verification of the Stable Release Update for nis has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package nis - 3.17-32ubuntu6.1

---------------
nis (3.17-32ubuntu6.1) trusty; urgency=medium

  * Make sure both characters in the salt are present before calling
    crypt() rather than just the first in yppasswd fixing operation
    with shadow passwords after a change in the behaviour of crypt()
    with invalid salts (LP: #1204530).
    This is a backport of the fix for debian bug 721737 to trusty.

 -- Christian Ehrhardt <email address hidden> Wed, 23 Mar 2016 11:38:10 +0100