Bug 9507 - mkpasswd script insecure
Summary: mkpasswd script insecure
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: tcltk
Version: 7.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jens Petersen
QA Contact:
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2000-02-17 00:30 UTC by dharris
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2001-06-15 03:28:15 UTC

Attachments (Terms of Use)
A file containing all passwords the insecure mkpasswd script will generate. (215.47 KB, application/octet-stream)
2001-04-13 19:51 UTC, Mike A. Harris
no flags Details

Description dharris 2000-02-17 00:30:02 UTC
NOTE: This bug is for the expect package, but that package is not listed
in your list, so I've put it under the passwd package for now as this is a
password setting security issue.

There is a script distributed called mkpasswd which creates and sets
passwords for users. The problem with this script is that it only uses the
PID of the current process as its random data source. Therefore, if a
cracker sees mkpasswd running in a process listing they can determine the
password generaged. If you are on the system and you know about when
mkpasswd ran, you should be able to narrow it down to a few hundred or a
few thousand possible passwords (depending on how busy the system is).

This is really bad when you notice that mkpassword has the option of
automatically using the generated password to set the login password of an
account. Ouch.

Either Red Hat should place a WARNING in the man page for this utility, or
upgrade it to gather random data from a better source like /dev/random or
completely remove it. I opt for removing it. Or rename it to mkpasswd-
insecure, so those who are using it can continue, but they have to change
their shell scripts and see the insecurity.

Comment 1 Cristian Gafton 2000-05-22 15:36:59 UTC
assigned to nalin

Comment 2 Mike A. Harris 2001-04-12 22:54:13 UTC
This script is part of the "expect" package.  There is no bugzilla
component for it.  An "rpm -qi expect" reveals it is from the tcltk package
so I am reassigning it there.  A report on bugtraq just surfaced about this,
claiming to have reported this a long time ago.  If we care about security
at all I think we should either remove the script entirely, or fix it to
be truely random.  Personally I'd remove it as such scripts are never

Comment 3 Mike A. Harris 2001-04-13 19:04:06 UTC
I have just confirmed that this script is totally garbage.
I ran it all night, and out of 869570 generated passwords, only
32167 passwords are unique.  Further generation of passwords will
only generate duplicate passwords.

Anyone knowing that a system is using this script to generate passwords
can easily generate the 32167 passwords in a few hours and brute force
attack a machine trivially both locally and remotely.  Even if a potential
intruder does not know if mkpasswd is being used, they could easily attempt
a brute force attack anyways, and if it is being used, they are likely
to compromise a user account.  ISP's and other organizations that use
such password generation are especially vulnerable.

Comment 4 Mike A. Harris 2001-04-13 19:49:30 UTC
I ran mkpasswd in a loop in the previous message.  I stored all generated
passwords in a file, sorted it removing duplicates, which I am attaching
to the bug report.  This is just to illustrate how trivial one could
do the same.

Comment 5 Mike A. Harris 2001-04-13 19:51:37 UTC
Created attachment 15333 [details]
A file containing all passwords the insecure mkpasswd script will generate.

Comment 6 Mike A. Harris 2001-06-15 03:28:09 UTC
This problem is still present in RHL 7.1 - changing release number.

Comment 7 Eido Inoue 2001-07-23 15:52:14 UTC
changed the expect mkpasswd script so use linux device /dev/urandom
(non-blocking /dev/random)

Comment 8 Mike A. Harris 2002-12-11 10:58:25 UTC
I just tested RHL 8.0 mkpasswd and it generated passwords for 2.5 hours in
a forkbomb.  ;o)  It was hard to get out of the accidental forkbomb (8 of
them actually) but I eventually did.  ;o)

Results:  418260 passwords generated, and 418260 were unique

In other words, no password was ever duplicated in over 418260 attempts.

I'd have to leave this going all night long to get better testing, but
I have a feeling it is much more secure now.

Note You need to log in before you can comment on or make changes to this bug.