crontab in Vixie cron 4.1, when running with the -e option, allows local users to read the cron files of other users by changing the file being edited to a symlink. NOTE: there is insufficient information to know whether this is a duplicate of CVE-2001-0235. http://www.securityfocus.com/archive/1/395093
This issue should also affect RHEL2.1 and RHEL3
Actually, in RHEL-3, vixie-cron-3.0.1-76 would not have this problem, becuase it used fstat(fd,&st) on the same original file descriptor for the file that was unlinked by the attack; since the modification time had not changed, it would print 'crontab: no changes made to crontab' and would not install the link as the new crontab. Because this version crontab did not re-open the file descriptor for the crontab temporary file name, it cannot be used with graphical EDITORs such as gedit / kedit, which do an unlink() and rename() when writing the file - this was fixed for bug 129170, which may have unwittingly opened the way for this exploit. This bug is now fixed with vixie-cron-4.1-33_EL4 (RHSA-2005:351-06) .
This bug is now fixed in RHEL-3 with vixie-cron-4.1-6_EL3 .
Re: comment #2 That should read this issue doesn't affect RHEL-2
RHEL-4: fixed with vixie-cron-4.1-33_EL4+ (errata RHSA-2005:351-06) RHEL-3: fixed with vixie-cron-4.1-6_EL3 (errata RHSA-2004:402-22)
Split bug 162022 for RHEL3
Our current fix for this issue is not complete. A race condition still exists between the time we lstat the file in question, and when we open the file.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-361.html