Crontab problems

[Warren Young]

Raphael wrote:
> I cannot see the security 
> issue for Cygwin as I now work arround by editing /var/cron/tabs/<currentuser>
> directly and restarting the service afterwards.

The security problem is a race condition.  Here's the scenario:

1. The crontab program makes a copy of the cron file to a temp file and 
then launches your $EDITOR on that file.

2. Editor reads file in, lets you modify it.  You say 'File | Save'.

3. Editor removes/renames temp file.

4. Security risk here.  (Details below.)

5. Editor creates a new file with the temp file name and writes file 
contents into it.

6. Editor exits, crontab installs new file and exits.

So what can happen at 4?  Here's one possibility which might even have 
a few variations:

1. Malicious program sits watching for crontab to start up, then watches 
the /tmp directory for new files.

2. A new file appears.  Now the malware sits waiting for it to disappear.

3. File disappears, and in the split second that it's gone the malware 
quickly writes out a new file with that name and keeps it open so that 
the $EDITOR can't write new contents into it.

4. Editor tries to open a new file with the temp file name for writing, 
but fails because there's already a file with that name.  User assumes 
that Windows is buggy (good guess, but wrong this time) and exits 
$EDITOR without saving.

5. The file is still open, but if you create the file with the right 
permissions it can still be read.  Crontab notices that the file has a 
new modification time, so it assumes that $EDITOR successfully rewrote 
the file; it reads the file and installs it.

6. At a time chosen by the malware's author, cron runs a program with 
Raphael's authentication token.  Since this is Windows, user Raphael is 
probably an Administrator.  One PC, cracked like an egg.

Since you're already editing the crontab file directly with an 
erase/rename-and-rewrite type of editor, you've opened yourself to this 
kind of security problem already.  I hope this worries you.

There are ways around this problem, at least under Unix type systems and 
probably also on systems running NTFS.  One is for crontab to make a 
directory under /tmp which is readable and writeable only by the user 
that owns the cron file, and to place the temp file into that directory. 
  Then the malware has no way of creating a file in that directory 
unless it already holds your authentication token, in which case there 
is little point to the attack to begin with.  This is a much bigger 
patch than making crontab close the file before handing it off to your 
$EDITOR, though.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/