This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Crontab problems

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:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]