Red Hat Bugzilla – Bug 72852
mkpasswd does not work with yppasswd
Last modified: 2007-11-30 17:10:30 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 Description of problem: The mkpasswd does not work on the NIS server. Here is why: 1. On line 16 and 17 of mkpasswd it refers to /bin/yppasswd. yppasswd is in /usr/bin so it is not found. 2. Ok we change the lines. When yppasswd runs as root it does not work the way passwd runs as root. The latter only asks for the new passwd to be typed twice. yppasswd required the root passwd to be entered before the new passwds are entered. In mkpasswd lines 193 and following the appropriate passwd changing program is called. But the mkpasswd script at that point has no provision for entering the root passwd so the mkpasswd script fails. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Have NIS running and yppasswd to be used to change passwd. ypbind is also running on the server 2.su - [on server] 3.mkpasswd username Actual Results: Failed preliminary check by password service rh3RV0ky@ Expected Results: the passwd of the user named should be changed and the passwd used should be displayed on the screen. Additional info: Note however that when mkpasswd runs it does not find yppasswd so it is passwd that is actually used. We can get expected results by stopping ypbind since mkpasswd username will work if it is not running since agin it is passwd username not yppasswd username that is actually running. I can't figure out why yppasswd run as root should require you to enter the root passwd.
mkpasswd is totally insecure and should be completely removed from the distribution. I've posted a bug report about this before, but it possibly has been closed WONTFIX or something (I dunno). The program is NOT truely random. It has a period of around 31000, and will only generate about that many random passwords. In a very short period of time, one person on one computer can brute force attack a system which is using mkpasswd to generate passwords. A search of all bugzilla bug reports for "mkpasswd" should turn up my report, and my script of proof for the above statements.
Here is the original bug report: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=9507 It claims it is fixed now. I don't know what version as it is not indicated. I'll test the latest version however, and see how truely random it is.
Havill's expect-5.32.2-random.patch is still in (has been since Jul 19 2001). So perhaps it is better now.
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 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.
Cool. Thank you for your testing. :)
Don't suppose it is any better in newer versions of expect?
It is frustrating to take so long to get any definitive response for this problem. makpasswd in RH 9 still uses yppasswd as a default with the same problem. However, there is a parameter to change it to use passwd. The locations of passwd and yppasswd are still wrong in the script. With all these changes it still hangs up to 20% of the time in an environment where mkpasswd is in a script that can be run by more than one person and protected by the lockfile command. So mkfile is still a problem.
Sorry for leaving this so long. My only concern if that since yp-tools seems to be installed by default, fixing this will break mkpasswd for people not using nis but with yp-tools installed. Perhaps it would be better to have two separate scripts: one for passwd and one for yppasswd? I don't use yppasswd myself, but if you are able to generate a mkyppasswd script I think I can add it to the expect package.
I have sent upstream a patch that asks the user for root's password if yppasswd is used. I agree with comment #8 that using yppasswd by default is not desirable, so not fixing the path in mkpasswd is probably better.