Pat (and Michael Semon): good job catching the login issue with glibc 2.17.

I've patched shadow 4.1.5.1 to properly handle NULL crypt() returns under
glibc 2.17+ and submitted it to upstream here.

However, I also wanted to share it with the Slackware community. So, here it is,
hot off the press. Patch applies against latest stable shadow 4.1.5.1.

Pat, your patch prevents the nonexistent user log-in issue Michael found but causes
undesired behavior in other callers. On a FIPS-140 system I tested with either
DES or MD5 ENCRYPT_METHOD, setting a new password will not fail as it should but
returns with apparent success having set password: "!!$6$8IIcy/1EPOk/$..."

You asked about other user-land potentially affected by the new crypt() behavior.
Below is a partial list I've put together that should help you as you work towards
the next release:

• sudo (fixed in 1.8.6p8)
• apache httpd (fixed in 2.2.23)
• screen (fixed in cbaa666d4f) [I recommend updating screen to something more recent]
• ppp (fixed in 04c4348108)

There are others I've not yet checked like: yptools, popa3d, etc. I will post things
as I discover them.

Cheers.

--mancha

Attached Files

Improve-handling-of-NULL-returns-from-crypt.patch.txt (7.2 KB, 31 views)

Thanks, mancha. Trying it out here now.

Update 5/19/13

• popa3d: Fixed by upstream for next stable release (v1.0.3)
  recommendation: given their long release cycle, apply my backport of
  their patch to latest stable 1.0.2 (see attached)
  
  
• tcsh: Upstream has accepted my patch;
  recommendation: apply my patch against 6.18.01 (see attached)
  
  
• yp-tools suite:
  
  
  1. ypserv: fixed in 2.28;
     recommendation: upgrade to at least version 2.28 but preferably ypserv 2.31
     
     
  2. yp-tools: not yet fixed; I've sent upstream a patch against latest stable;
     recommendation: upgrade to yp-tools 2.14 and apply my patch (see attached)
     
     
  3. ypbind-mt: unaffected;
     recommendation: upgrade to ypbind-mt 1.37.1

--mancha

Attached Files

	popa3d-1.0.2-crypt.diff.txt (1.6 KB, 20 views)
	tcsh-6.18.01-crypt.diff.txt (332 Bytes, 23 views)

1 members found this post helpful.

Update 5/22/13

A small bug slipped into the yp-tools patch. The result is an unnecessary call to crypt().

Please update with corrected patch.

Cheers.

--mancha

Attached Files

yp-tools-2.14-crypt-1.diff.txt (2.2 KB, 22 views)

1 members found this post helpful.

You had my attention when you used the word bug, but I have a different idea of what that word actually means. Both versions of the patch look to me like they work the same. The second version would be more efficient since it doesn't call crypt twice, but in practice there's probably no way you'd ever be able to notice (or benchmark) a difference.

To me, if you couldn't invent a unit test that shows the first patch has a problem fixed by the second patch, then there is no bug.

1 members found this post helpful.

Update 6/11/2013

• xdm: upstream committed my fix
  recommendation: apply my patch to xdm 1.1.11
  
  
• cvs: my fix is here
  recommendation: apply my patch to CVS 1.11.23
  
  
• dropbear: upstream has fixed;
  recommendation: apply upstream's patch to dropbear (note: might have to upgrade slackware's 2008 dropbear)

--mancha

1 members found this post helpful.

Update 6/29/13

• KDE/kdm: KDE accepted my fix (to be included in KDE Workspace 4.11).
  recommendation: Upgrade to KDE Workspace 4.10.5 and apply changeset patch.
  
  
• KDE/kcheckpass: KDE accepted my fix (to be included in KDE Workspace 4.11).
  recommendation: Same as above; fix included in above changeset.
  
  
• gdm: Not a stock Slackware package but generously maintained by Robby Workman on SBo.
  recommendation: gdm users on -current should sync with SBo which now includes my fix.

--mancha

1 members found this post helpful.

Update 7/2/13

Note: The backport commit with my fixes for KDE/kdm & KDE/kcheckpass missed the tag/release
deadline for 4.10.5 by 1 or 2 days. I edited the recommendations in post #7 above.

1 members found this post helpful.

Update 7/3/13

Others have expressed interest in the work I have been documenting here but don't always have access to LQ download links.

So, I have uploaded all patches referenced so far to a sourceforge project. From here on in, I will provide upstream links to
patches (if possible) and mirror on sourceforge rather than upload to LQ directly.

Digest file will be signed with the following key:

--mancha

1 members found this post helpful.

Update 7/10/13

• SLiM: Not a stock Slackware package but offered by SBo. Upstream has accepted my fix, SBo is aware, and will probably include the patch in the near future.
  recommendation: SLiM users on Slackware-current should re-build SLiM 1.3.5 with my patch.
  
  
• Openswan: Upstream has committed my fix.
  recommendation: IPsec/Openswan users on Slackware-current should re-build Openswan 2.6.39 with my patch.

--mancha

1 members found this post helpful.

Update 7/12/2013

For Slackware's 20th, I give it and the community a bit more of my code...

• cyrus-sasl: Upstream has committed my fix to their master branch.
  recommendation: re-build cyrus-sasl 2.1.23 with my backported patch. Alternatively, if you want to upgrade to cyrus-2.1.26 apply
  this backported patch. Note, if you go with 2.1.26, you should probably apply this upstream commit missed in that release.
  [CVE-2013-4122]

--mancha

1 members found this post helpful.

Update 7/15/13

• xlockmore: Upstream has accepted my fix and included it in the just-released xlockmore 5.43.
  recommendation: upgrade to xlockmore 5.43.
  [CVE-2013-4143]

--mancha

1 members found this post helpful.

Update 7/24/13


This concludes phase 1 of my audit of userland affected by glibc crypt changes. A considerable amount
of code was reviewed and fixes developed. CVE identifiers were requested for the more serious security
vulnerabilities.

While not exhaustive, I believe I've covered all stock Slackware packages affected so Slackware 14.1
should be good to go on that front. I've also looked into a few SBo offerings.

During phase 2 I will not actively search for vulnerable program suites but will continue to use this
thread to alert the community about any additional problems and/or fixes I come across or author during
my normal usage.


--mancha

4 members found this post helpful.

Thanks for your efforts mancha.

1 members found this post helpful.

Thanks mancha, your help was greatly appreciated!

2 members found this post helpful.