From jun@mew.gol.ad.jp  Sat Jun 27 08:13:16 1998
Received: from mew.gol.ad.jp (mew.gol.ad.jp [203.216.0.88])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA20802
          for <FreeBSD-gnats-submit@freebsd.org>; Sat, 27 Jun 1998 08:13:15 -0700 (PDT)
          (envelope-from jun@mew.gol.ad.jp)
Received: (from jun@localhost)
	by mew.gol.ad.jp (8.8.8/8.8.8) id AAA26526;
	Sun, 28 Jun 1998 00:13:13 +0900 (JST)
	(envelope-from jun)
Message-Id: <199806271513.AAA26526@mew.gol.ad.jp>
Date: Sun, 28 Jun 1998 00:13:13 +0900 (JST)
From: Just Another Perl Hacker <japh@gol.com>
Reply-To: japh@gol.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: crypt(3) partially returns raw password when salt isn't null-terminated
X-Send-Pr-Version: 3.2

>Number:         7090
>Category:       ports
>Synopsis:       xlock manhandles crypt(3) API.
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    tg
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Jun 27 08:20:00 PDT 1998
>Closed-Date:    Mon Aug 3 01:09:59 PDT 1998
>Last-Modified:  Mon Aug  3 01:11:43 PDT 1998
>Originator:     Junichi Kurokawa, AKA Just Another Perl Hacker
>Release:        FreeBSD 2.2.6-RELEASE i386
>Organization:
Global Online Japan Corporation, Tokyo
>Environment:

	FreeBSD 2.2.6-RELEASE, with MD5 based libcrypt

>Description:

	MD5 based crypt(3) in libcrypt.{a,so.maj.min} as distributed
	by FreeBSD returns a portion of the password in the clear,
	when the salt isn't terminated by a null character.

	Example:

	crypt("abcdefgh","YX") returns <$1$YXabcdef$.tHXoLufzR8OYyH4BBghm1
                                             ^^^^^^
	This problem surfaces when an application that assumes a salt
	is an array of two characters with no trailing null character
	calls crypt(3).  Such an example is xlock(1), with USE_XLOCKRC
	defined in the compilation.

	This is actually an operating system problem of FreeBSD that
	can cause any C based application to reproduce; however, only
	FreeBSD seems to have both this problem shown herein, and an
	implementation of crypt(3) that does not assume that a salt is
	a two bytes array with no terminating null character.

	DESfied crypt(3) therefore does not exhibit this problem.
	Also, FreeBSD's /usr/bin/passwd(1) command puts a null
	character with a salt correctly when calling crypt(3).

>How-To-Repeat:

	The following code demonstrates that a portioin of the raw
	password is exposed in an output of crypt(3).

		#include <stdio.h>
		#include <stdlib.h>
		#include <string.h>
		#include <unistd.h>
		
		#define PW "abcdefgh"
		
		int
		main(int argc, char** argv)
		{
		
		 char pw[sizeof PW];
		 char salt[2];
		
		 strncpy(pw,PW,sizeof PW);
		 salt[0]='Y';
		 salt[1]='X';
		
		 fprintf(stdout,"password is <%s>.\n",pw);
		 fprintf(stdout,"salt is <%s>.\n",salt);
		 fprintf(stdout,"crypt(3) returned <%s>.\n",crypt(pw,salt));
		 return EXIT_SUCCESS;
		}

	    % ./followingcode
	    password is <abcdefgh>.
	    salt is <YXabcdefgh>.
	    crypt(3) returned <$1$YXabcdef$.tHXoLufzR8OYyH4BBghm1>.

	The salt seen at the second line should merely have been <YX>,
	as well as the salt contained in the crypt(3)'s output which
	is followed by a portion of the raw password.

>Fix:
	Workaround: always terminate a salt with a null character.
	Modify the source of an application when necessary.

	Real Fix: refrain any use of crypt(3) altogether, until a
	meaningful replacement of crypt(3) is implemented;
	e.g. md5_crypt(3) as opposed to des_crypt(3), such that a salt
	is wholelly copied onto the stack instead of pointed by a
	pointer when passed to md5_crypt(3).

	Comment to Maintainer: should I submit md5_crypt(3)?
>Release-Note:
>Audit-Trail:

From: Poul-Henning Kamp <phk@critter.freebsd.dk>
To: japh@gol.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/7090: crypt(3) partially returns raw password when salt isn't null-terminated 
Date: Sat, 27 Jun 1998 18:10:57 +0200

 >	MD5 based crypt(3) in libcrypt.{a,so.maj.min} as distributed
 >	by FreeBSD returns a portion of the password in the clear,
 >	when the salt isn't terminated by a null character.
 >
 >	Example:
 >
 >	crypt("abcdefgh","YX") returns <$1$YXabcdef$.tHXoLufzR8OYyH4BBghm1
 >                                             ^^^^^^
 >	This problem surfaces when an application that assumes a salt
 >	is an array of two characters with no trailing null character
 >	calls crypt(3).  Such an example is xlock(1), with USE_XLOCKRC
 >	defined in the compilation.
 
 Then xlock doesn't use the crypt API correctly and should be fixed.
 
 --
 Poul-Henning Kamp             FreeBSD coreteam member
 phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
 "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal
Responsible-Changed-From-To: freebsd-bugs->freebsd-ports 
Responsible-Changed-By: phk 
Responsible-Changed-When: Sat Jun 27 09:26:56 PDT 1998 
Responsible-Changed-Why:  
xlock issue. 

From: Bill Fenner <fenner@parc.xerox.com>
To: Just Another Perl Hacker <japh@gol.com>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/7090: crypt(3) partially returns raw password when salt isn't null-terminated 
Date: Sat, 27 Jun 1998 12:21:37 PDT

 In message <oiulmvj0v.fsf@mew.gol.ad.jp>you write:
 >Refer to the manpages of
 >other operating systems, e.g. BSD/OS, Linux, Sun.
 
 The SunOS, BSD4.3, OSF/1, Solaris, and IRIX man pages all say:
 
      The  second [argument to crypt] is a 2-character string chosen from
      the set [a-zA-Z0-9./].
 
 The Single UNIX  Specification, Version 2 says:
 
 The key argument points to a string to be encoded.  The salt argument
 is a string chosen from the set: [...]
 
 All of these pieces of documentation say that the salt argument is
 a string.  Strings are null terminated.  Since crypt()'s 2nd argument
 is documented to be a string, xlock is wrong to pass in something
 that's not a string (even though it appears to work on most OS's).
 
   Bill

From: Poul-Henning Kamp <phk@critter.freebsd.dk>
To: Just Another Perl Hacker <japh@gol.com>
Cc: FreeBSD-bugs@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/7090: crypt(3) partially returns raw password when salt isn't null-terminated 
Date: Sun, 28 Jun 1998 00:00:18 +0200

 >It is therefore FreeBSD's fault in not expecting non-terminated salts,
 >while providing a compatible API with an incompatible behaviour which
 >results the blatantly wrong output.  You missed my point.
 
 No I didn't, I carefully surveyed the issue back in 1994 when I
 wrote the MD5 based crypt(3), and found that only very few programs
 were brain-damaged enough to peek into the internals of the crypt
 implementation this way.
 
 Most sane users simply pass the entrypted password they have found
 in the passwd file as salt arg to crypt, which means that the
 crypt(3) can chew it up any way it wants to, and you will work both
 with the "old DES", which you refer to, the "new DES" which takes
 a 9 character salt or the MD5 based "$1$" one which takes a 12 char
 salt or the OpenBSD "$2a$" SHS based with has a salt longer than
 the number of atoms in the universe...
 
 Remember: "Be conservative in what you send and liberal in what you
 expect".
 
 QED: xlock has no business knowing that salts are X characters for any
 value of X.
 
 --
 Poul-Henning Kamp             FreeBSD coreteam member
 phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
 "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal
Responsible-Changed-From-To: freebsd-ports->tg 
Responsible-Changed-By: obrien 
Responsible-Changed-When: Tue Jul 28 10:44:31 PDT 1998 
Responsible-Changed-Why:  
tg is the maintainer 
State-Changed-From-To: open->closed 
State-Changed-By: tg 
State-Changed-When: Mon Aug 3 01:09:59 PDT 1998 
State-Changed-Why:  
I have added a patch which hopefully does the right thing. Note that 
you need to adjust the CONFIGURE_ARGS by hand to actually use the 
functionality in xlock. 
. 
>Unformatted:
