CSE 643 - Computer Security - Race Condition

How many race conditions does attackers have to win in the following program? int main() { struct stat stat1, stat2; int fd1, fd2; if (access("tmp/XYZ", O_RDWR)) { fprintf(stderr, "Permission denied\n"); return -1; } else fd1 = open("/tmp/XYZ", O_RDWR); if (access("tmp/XYZ", O_RDWR)) { fprintf(stderr, "Permission denied\n"); return -1; } else fd2 = open("/tmp/XYZ", O_RDWR); // Check whether fd1 and fd2 have the same inode. fstat(fd1, &stat1); fstat(fd2, &stat2); if(stat1.st_ino == stat2.st_ino) { write_to_file(fd1); } else { fprintf(stderr, "Race condition detected\n"); return -1; } return 0; }

3 assuming all filenames are /tmp/XYZ and not tmp/XYZ as incorrectly noted in some places. The first race is between access & fd1 open, where we have to create a symlink from /tmp/XYZ to a file the we want to change. The second is between fd1 open and the second access, where we have to update the symlink and point it to a file the user can access. The third is between the second access and fd2 open, similar to the first race.

If we can lock a file, we can solve the race condition problem by locking a file during the check-and-use window, because no other process can use the file during the time window. Why don't we use this approach to solve the race condition problems discussed in this chapter?

A file is locked out to other processes only if it's already open. During the check-and-open process, it's impossible to lock a file. Any locks created can be ignored by the malicious process.

The least-privilege principle can be used to effectively defend against the race condition attacks discussed in this chapter. Can we use the same principle to defeat buffer-overflow attacks? Why or why not? Namely, before executing the vulnerable function, we disable the root privilege; after the vulnerable function returns, we enable the privilege back.

If the question is referring to disabling root privileges before the strcpy() call, and enabling it after, it won't work, as the actual attack happens when we return from the bof() function. If we disable root privileges before the bof() call and enable it after, then we can prevent the attack.

In the open() system call, it first checks whether the user has the required permission to access the target file, then it actually opens the file. There seems to be a check-and-then use pattern. Is there a race condition problem caused by this pattern?

In the open() system call, the check for user permission and opening of the file is an atomic operation, so there is no race condition possible with just an open() call.

Does the following program have a race condition vulnerability? if (!access("/etc/passwd", W_OK)) { /* the real user has the write permission*/ f = open("/tmp/X", O_WRITE); write_to_file(f); } else { /* the real user does not have the write permission */ fprintf(stderr, "Permission denied\n"); }

No. /etc/passwd is a protected file, and normal users don't have *write* access to it. So the if block will never be executed.