This is the mail archive of the
mailing list for the Cygwin project.
Re: Crontab problems
I cannot see the security
issue for Cygwin as I now work arround by editing /var/cron/tabs/<currentuser>
The security problem is a race condition. Here's the scenario:
directly and restarting the service afterwards.
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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html