Bugzilla Bug 164466

Hi,

i may have found a problem in some implementations of cron.
vixie-cron and fcron are concerned, dcron is not; i haven't checked other ones.

cron checks if the crontab files have st_nlink==1, and if not, cron doesn't
execute those files.

If /home is not on a separate partition, i can :
ln /etc/crontab .
(then wait for a reload, or force a reload with crontab -e)
and the cron service is nearly entirely shut down
(/etc/cron.daily|monthy|hourly)

i can also ln /etc/cron.d/* to deny the execution of those files

finally if i am in the crontab group, i can cd /var/tmp (which is usually
rwrwrw), and "ln /var/spool/cron/crontabs/user ."
I force a cron reload with a quick "crontab -e"

Jan 29 21:16:01 localhost cron[6014]: (*system*) BAD LINK COUNT
(/etc/cron.d/test)
Jan 29 21:11:01 localhost cron[6014]: (*system*) BAD LINK COUNT (/etc/crontab)
Jan 29 21:11:01 localhost cron[6014]: (falco) BAD LINK COUNT (crontabs/falco)

Debian has the same behaviour, but the access to /var/spool/cron/crontabs is
more restricted.
Jan 29 22:09:01 djali /usr/sbin/cron[10918]: (x2002marichez) WRONG INODE INFO
(crontabs/x2002marichez)




i restrict this bug today, but it may be useful to get some feedback from
several developers. This check is probably here for some reason...!

Aaron, Wolfram, do you have an idea on why does this st_nlink check exist? Do
you have any comment?

FCron (2 and 3) only seems to check link count for temporary files.
Thus, it does not seem to be affected.

(In reply to comment #2)
> FCron (2 and 3) only seems to check link count for temporary files.
> Thus, it does not seem to be affected.
> 

Right, thanks.

But vixie-cron doesn't deal with that kind of temporary files. It really checks
st_nlinks on the real crontabs.

Vapier do you have any clue here? I'm still looking for a possible reason why
does vixie-cron check st_links==1 on its crontabs, allowing for a local DoS
throught hardlinks created on /etc/crontab /etc/cron.*/* /var/spool...etc

i cant guess; seems like a dumb check

so i'd tend to ask to Wolfram if he wants to patch that and fix it. I don't
know how to handle that issue without an active upstream.

Sorry, but I have nothing to do with vixie-cron  -- only fcron :-)

So what is going to happen here?

Falco, do you want to contact upstream? Might be best.

vorlon, i wanted to contact upstream but i'm afraid there's no upstream.

Falco, any news on this one?

(In reply to comment #9)
> Falco, any news on this one?
> 


i wish to talk about it on v-sec but i'm not officially introduced yet.

Falco, any more news on this one?

Hi dear arches security liaisons,

please test vixie-cron-4.1-r10 which changes vixie-cron behaviour on
/var/spool/cron/crontabs. Upgrade should be OK, so should the new
installations, but please test it deeply since it's a major package, and don't
hesitate to comment.

After upgrading , /var/spool/cron/crontabs should be :
drwx-wx--T 2 root crontab
And inside:
-rw------- 1 apache crontab  417 Mar 11 20:53 apache
-rw------- 1 falco  crontab 1.1K Apr  8 23:36 falco
etc
And /usr/bin/crontab is no longer SUID, but now SGID.

Very few linux distros are concerned by this bug so i think we will disclose it
very soon. No need to urge here, you can just report on that bug if the tests
are OK. Thanks in advance.

(In reply to comment #12)
> please test vixie-cron-4.1-r10

fine on ppc64. no stable marking yet?

Hi arches,

you can now mark it stable if it runs fine for you, since it's already
partially public via the OWL patch
http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/vixie-cron/vixie-cron-4.1.20060426-owl-st_nlink.diff

Goes public now, removing liaisons and adding arch aliases. Please see comment
#12.

x86 + ia64 stable

sparc stable.
would have been good to remove the liasons when adding arches too...

emerges fine and works on amd64

Portage 2.1.2.2 (default-linux/amd64/2006.1/desktop, gcc-4.1.1, glibc-2.5-r0,
2.6.20-beyond2 x86_64)
=================================================================
System uname: 2.6.20-beyond2 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor
4600+
Gentoo Base System release 1.12.9
Timestamp of tree: Tue, 10 Apr 2007 15:20:01 +0000
ccache version 2.4 [enabled]
dev-java/java-config: 1.3.7, 2.0.31-r5
dev-lang/python:     2.4.3-r4
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.4-r6
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.61
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.14
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.17-r2
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=k8 -Os -pipe -msse3 -w"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf
/etc/java-config/vms/ /etc/php/apache1-php5/ext-active/
/etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/
/etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo"
CXXFLAGS="-march=k8 -Os -pipe -msse3 -w"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--quiet"
FEATURES="buildsyspkg ccache collision-protect distlocks metadata-transfer
multilib-strict parallel-fetch sandbox sfperms strict test"
GENTOO_MIRRORS="ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/
ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo
ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo
ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo
ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo
ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/
ftp://ftp.gentoo.mesh-solutions.com/gentoo/
ftp://pandemonium.tiscali.de/pub/gentoo/ "
LANG="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
MAKEOPTS="-j3 -l3 -s"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages
--filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage/overlay"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="X a52 aac acpi alsa amd64 amr audiofile bitmap-fonts bzip2 cairo cdinstall
cdr cli cracklib crypt cups dbus dri dts dvd dvdr dvdread emboss encode exif
fam firefox fortran gdbm gif gstreamer gtk gtk2 hal iconv jpeg libg++ logrotate
mad midi mikmod minimal mp3 mpeg ncurses nptl nptlonly offensive ogg opengl pam
pcre php png ppds pppd quicktime readline reflection sdl session smp spl ssl
svg symlink tcpd test tiff truetype truetype-fonts type1-fonts unicode v4l vim
vorbis x264 xinerama xorg xv xvid zlib" ALSA_CARDS="emu10k1"
ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file
hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route
share shm softvol" ELIBC="glibc" INPUT_DEVICES="evdev keyboard" KERNEL="linux"
LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses
text" LIRC_DEVICES="inputlirc" USERLAND="GNU" VIDEO_CARDS="nvidia"
Unset:  CTARGET, INSTALL_MASK, LDFLAGS, LINGUAS, PORTAGE_COMPRESS,
PORTAGE_COMPRESS_FLAGS

amd64 stable!

ppc64 stable

Stable for HPPA (killerfox).

ppc stable

Alpha done.

GLSA 200704-11

thanks everyone once again :)