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.
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.