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.
assigned to nalin
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 secure.
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.
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.
Created attachment 15333 [details] A file containing all passwords the insecure mkpasswd script will generate.
This problem is still present in RHL 7.1 - changing release number.
changed the expect mkpasswd script so use linux device /dev/urandom (non-blocking /dev/random)
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.