Subject: Re: /etc/passwd migration between systems

From: Jim Worthington <[email-masked]>
Date: Sat, 24 Aug 1996 13:07:07 -0400

Bruce Perens wrote:
> This must be a bug.
>         Bruce

Can anybody verify this?

Also I get the following message when trying to run crack ver 4.1:

 Crack v4.1f: The Password Cracker, (c) Alec D.E. Muffett, 1992

 Version of crypt() being used internally is not compatible with
 standard.

Has anybody successfully been able to run crack on Debian Linux 1.1?

Jim

---

From: [email-masked] (Gilbert Ramirez Jr.)
Date: Sat, 24 Aug 1996 16:20:39 -0500 (CDT)

> Has anybody successfully been able to run crack on Debian Linux 1.1?

Randy Gobbel and I are looking at Crack right now on Linux (kernel 2.0.12).

If you make FCRYPT equal to null in Sources/Makefile, and possibly remove
references to FCRYPT, you can successfully compile and run Crack. To me it
seems like the Makefile is configure to either use fcrypt or UFC, but not a
standard crypt. This is because most standard crypts are SLOW. But the
Linux crypt is very fast. Change the Makefile like so:

FCRYPT=

However.....

Using the default -O optimization makes Crack stop when it begins applying
the rules that append numeric digits to the end of a word (near the end of
dict.rules).  Randy's mahcine (586) freezes, while mine (486) merely dumps
core.

If you replace -O with -g, in an attempt to run gdb on it, Crack runs fine
all the way through the end of the rules. But, when Crack is about to write
the final information to file, it messes up again. On Randy's machine,
inodes get messed up. On mine, the file is written to disk, but under a
garbage name.... 250+ characters of random punctuation and control
characters. I did not count the number of characters... 256 would be an
interesting number.

Randy & I aren't sure what's causing the problem. Any help at all would be
appreciated. There are 3 places I see that could contian a bug:

1) Crack
2) libc
3) the kernel

This is my first time running Crack, so I don't know if it ran well before
on 1.2.x kernels, or on other Unices.

libc might be at fault, because of the weird disk events that happen when
Crack finishes.

Or the kernel might be at fault... my Crack (!) dumps core, but Randy's
machine totally freezes.

If anyone would like to compile Crack and help in our effort to find the
bug, you can get the sources at http://www.deter.com , in one of the
sub-pages.

Thanks!

--gilbert

______________________________________________________________________
Gilbert Ramirez Jr.                     [email-masked]
University of Texas                     http://merece.uthscsa.edu/gram
Health Science Center at San Antonio    University Health System

---

From: Jim Worthington <[email-masked]>
Date: Sat, 24 Aug 1996 18:36:35 -0400

> Linux crypt is very fast. Change the Makefile like so:

Gilbert,

I've tried UFC CRYPT in addition to FCRYPT with equally un-successful
results.  The use of standard crypt makes sense as you suggest, however,
I believe that the crypt which is distributed with Debian 1.1 is broken,
or at least incompatable with the standard Unix crypt algorithm. 
Whether this is a bug or a security enhancement is unknown.

I do know that when I tried to copy my /etc/passwd file from a Sun
system to Debian 1.1, the passwords would not decrypt correctly on
login.  Since the passwd file that I'm trying to test is not native to
Debian Linux, the native Debian crypt algorithm won't be much use in
it's incompatible state.

I do get some warning messages when crack is invoked.  Perhaps this is
related to why it won't run:   Any Ideas?

bytesex.c: In function `main':
bytesex.c:19: warning: left shift count >= width of type
crack-pwc.c: In function `TryManyUsers':
crack-pwc.c:556: warning: passing arg 2 of `strcpy' makes pointer from
integer without a cast
crack-pwc.c: In function `TryOneUser':
crack-pwc.c:598: warning: passing arg 1 of `strcmp' makes pointer from
integer without a cast
crack-pwc.c: In function `main':
crack-pwc.c:1094: warning: passing arg 1 of `strcmp' makes pointer from
integer without a cast

The version of crack that I am using is 4.1f.  I thought that somebody
on this list made reference to version 4.5 about a week ago.  Do you
know what the most recent version is and where it can be obtained?

Jim  <[email-masked]>

---

From: [email-masked] (Gilbert Ramirez Jr.)
Date: Sat, 24 Aug 1996 21:51:52 -0500 (CDT)

> Debian Linux, the native Debian crypt algorithm won't be much use in

I've sent this to Jim already, but I'm re-sending it to the list.

I can get Crack 4.1 to work to a point, but it either

	1) seg-faults near the end, when I compile with -O

	2) creates a garbage filename for the final output file, the filename 
		is around 250 bytes (256??) of punctuation and control characters.
		This is when I compile with -g

I ran #2 on a passwd file from a SunOS 4.1.3 machine, and it worked. Crack
was able to crack 4 of the users' passwords. So, the crypt() functions from
SunOS 4.1.3 and Linux 2.0.12 (er, libc 5.whatever) running on a 486
are compatible.

However Jim is seeing an anomaly on his machine. I'm also getting strange
behaviour from Crypt, and so is Randy Gobbel. I get segfaults or strange
filesystem behavior, and Randy's machine freezes, or also has strange
filesystem behavior.

Any more strange tales from the crypt() ? (sorry... my attempt at humor)

--gilbert

---

From: [email-masked] (Miquel van Smoorenburg)
Date: 25 Aug 1996 13:25:56 +0200

In article <[email-masked]>,
>Whether this is a bug or a security enhancement is unknown.

I can assure you that the crypt included in the Linux libc is compatible
with other Unix crypts. We are using NIS in our internal network, and
I've worked with Solaris NIS servers, SunOS NIS servers and Linux NIS
servers (now only using the Linux NIS server) with accounts/passwords
generated on all of them. Everything can talk with eachother.

Please don't spread around such misinformation about Linux and/or Debian.
It is bad publicity, and does hurt us all.

I don't know what problem you are seeing with Crack, but I compiled
it myself a couple of months ago with no trouble what so ever.

Mike.
-- 
+   Miquel van Smoorenburg   + Cistron Internet Services +  Living is a     |
|  [email-masked] (SP6)  | Independent Dutch ISP     |   horizontal     |
+ [email-masked] + http://www.cistron.nl/    +      fall        +

---

From: [email-masked] (Wayne Schlitt)
Date: Sun, 25 Aug 1996 10:15:45 -0500

> > login.

Just another data point....  I just copied my passwords from my SVR4
Dell Unix system to Linux, and they worked fine.  I didn't just copy
the /etc/passwd file because I wanted to preserve some of the default
logins that Debian gives, and I also had to snarf the passwords out of
/etc/shadow.

In the past, I have also copied passwords from HP-UX, Sun OS, and SGI
machines to my Dell machine, so I would say that all of these systems
must use the same format.

-wayne

---

From: Bill Wohler <[email-masked]>
Date: Mon, 26 Aug 1996 12:10:53 -0700

Wayne Schlitt <[email-masked]> writes:
> Dell Unix system to Linux, and they worked fine.

  And another data point (for Crack).  My old binary of Crack works on
  Debian 1.1, HP-UX 9.*, and SunOS password files also.  I also
  recompiled it and it still works on the SunOS file.

  Also tried logging in with an HP-UX password.  Also worked fine in 1.1.

Bill Wohler <[email-masked]>   ph: +1-415-854-1857  fax: +1-415-854-3195
Say it with MIME.  Maintainer of comp.mail.mh and news.software.nn FAQs.
If you're passed on the right, you're in the wrong lane.

---

From: [email-masked] (Martin Dinkloh)
Date: 27 Aug 1996 11:05:19 GMT

Jim Worthington ([email-masked]) wrote:
[...]
: Also I get the following message when trying to run crack ver 4.1:
: 
:  Crack v4.1f: The Password Cracker, (c) Alec D.E. Muffett, 1992
: 
:  Version of crypt() being used internally is not compatible with
:  standard.
: 
: Has anybody successfully been able to run crack on Debian Linux 1.1?
[...]

You need to install ufc-crypt in your CRACK_HOME-Directory. After that 
'$CRACK_HOME/Crack' recognizes ufc-crypt by itself.

'ufc-crypt.tar.gz' is the name of the archiv you need to get.

Martin

---

From: Mark Eichin <[email-masked]>
Date: 30 Aug 1996 04:02:17 -0400

Last time I ran into it, it turned out that for *legitimate* salts,
the linux crypt() was compatible, but for out-of-range ones, there
were differing results.   An easy way to test is to use perl. For
example:

solaris2.4+% perl -e 'print crypt("pass", "ab")."\n"'
abccBcrPOxnLU
solaris2.4+% perl -e 'print crypt("pass", "++")."\n"'
++kT1mYjlikoI
debian1.1+% perl -e 'print crypt("pass", "ab")."\n"'
abccBcrPOxnLU
debian1.1+% perl -e 'print crypt("pass", "++")."\n"'
++1clPVO6npvw

Note that with a salt of "ab" they match, but with a salt of "++" they
don't.  Classic crypt() used 4096 legal salts (":" was obviously out, I
don't recall exactly what range was used.)

If anything, the bug is that the solaris system is generating "out of
range" salt values...