Secure Coding in C and C++ Race conditionsConcurrency and Race conditionRace conditionRace windowTime of Check, Time of UseExampleTOCTOUTOCTUFile lockingSlide 10File System ExploitsSymbolic linking exploitsSlide 13Slide 14Slide 15Slide 16Slide 17Temporary file open exploitsSlide 19Slide 20ulink Race exploitsTrusted filenamesNonunique Temp File NamesMitigation strategiesSlide 25Slide 26Thread safe functionUse of atomic operationsChecking file properties securelySlide 30Eliminating the race objectSlide 32Controlling access to the race objectRace detection toolsSlide 35Secure Coding in C and C++Race conditionsLecture 8Acknowledgement: These slides are based on author Seacord’s original presentationConcurrency and Race conditionConcurrencyExecution of Multiple flows (threads, processes, tasks, etc)If not controlled can lead to nondeterministic behaviorRace conditionsSoftware defect/vulnerability resulting from unanticipated execution ordering of concurrent flowsE.g., two people simultaneously try to modify the same account (withrawing money)Race conditionNecessary properties for a race conditionConcurrency propertyAt least two control flows executing concurrentlyShared object propertyThe concurrent flows must access a common shared race objectChange state propertyAtleast one control flow must alter the state of the race objectRace windowA code segment that accesses the race object in a way that opens a window of opportunity for race conditionSometimes referred to as critical sectionTraditional approachEnsure race windows do not overlapMake them mutually exclusiveLanguage facilities – synchronization primitives (SP)Deadlock is a risk related to SPDenial of serviceTime of Check, Time of UseSource of race conditionsTrusted (tightly coupled threads of execution) or untrusted control flows (separate application or process)ToCToU race conditionsCan occur during file I/OForms a RW by first checking some race object and then using itExampleAssume the program is running with an effective UID of rootint main(int argc, char *argv[]) {FILE *fd; if (access(“/some_file”, W_OK) == 0) { printf("access granted.\n"); fd = fopen(“/some_file”, "wb+"); /* write to the file */ fclose(fd); } else { err(1, "ERROR"); } return 0;} Figure 7-1int main(int argc, char *argv[]) {FILE *fd; if (access(“/some_file”, W_OK) == 0) { printf("access granted.\n"); fd = fopen(“/some_file”, "wb+"); /* write to the file */ fclose(fd); } else { err(1, "ERROR"); } return 0;} Figure 7-1TOCTOUFollowing shell commands during RWrm /some_fileln /myfile /some_fileMitigationReplace access() call by code that does the followingDrops the privilege to the real UIDOpen with fopen() & Check to ensure that the file was opened successfullyTOCTUNot all untrusted RCs are purely TOCTOUE.g., GNU file utilitiesExploit is the following shell commandmv /tmp/a/b/c /tmp/cNote there is no checking here - implicitchdir(“/tmp/a”);chdir(“b”);chdir(“c”); //race windowchdir(“..”);chdir(“c”);ulink(“*”); chdir(“/tmp/a”);chdir(“b”);chdir(“c”); //race windowchdir(“..”);chdir(“c”);ulink(“*”);File lockingSynchronization Primitives cannot be used to resolve RC from independent processesDon’t have shared access to global dataFile locks can be used to synchronize themint lock(char *fn) { int fd; int sleep_time = 100; while (((fd=open(fn, O_WRONLY | O_EXCL | O_CREAT, 0)) == -1) && errno == EEXIST) { usleep(sleep_time); sleep_time *= 2; if (sleep_time > MAX_SLEEP) sleep_time = MAX_SLEEP; } return fd;}void unlock(char *fn) { if (unlink(fn) == -1) { err(1, "file unlock"); }} Figure 7-3int lock(char *fn) { int fd; int sleep_time = 100; while (((fd=open(fn, O_WRONLY | O_EXCL | O_CREAT, 0)) == -1) && errno == EEXIST) { usleep(sleep_time); sleep_time *= 2; if (sleep_time > MAX_SLEEP) sleep_time = MAX_SLEEP; } return fd;}void unlock(char *fn) { if (unlink(fn) == -1) { err(1, "file unlock"); }} Figure 7-3File lockingTwo disadvantagesOpen() does not blockUse sleep_time that doubles at each attempt (also known as spinlock or busy form of waiting)File lock can remain locked indefinitely (e.g., if the locking process crashes)A common fix is to store the PID in the lock file, which is checked against the active PID. Flaws with this fixPID may have been reusedFix itself may contain race conditionsShared resource may also have been corrupted because of the crashFile System ExploitsFiles and directories are common race objectsOpen files are shared by peer threadsFile systems have exposure to other processesAs file permissionsFile naming conventionsFile systems mechanisms Most executing programs leave a file in a corrupted state when it crashes (backup is remedy)ExploitsSymbolic linking exploitsTemporary file open exploitsulink() race exploitTrusted filenamesNonunique temp file namesSymbolic linking exploitsUnix symbolic linking is most commonSymlink is a directory entry that references a target file or directoryVulnerability involves programmatic reference to a filename that unexpectedly turns out to include a symbolic linkIn the RW the attacker alters the meaning of the filename by creating a symlinkSymbolic linking exploitsAttacker does:rm /some_dir/some_fileln –s attacker_file /some_dir/some_file if (stat(“/some_dir/some_file”, &statbuf) == -1) { err(1, "stat"); } if (statbuf.st_size >= MAX_FILE_SIZE) { err(2, "file size"); } if ((fd=open(“/some_dir/some_file”, O_RDONLY)) == -1) { err(3, "open - %s",argv[1]); } Figure 7-4 if (stat(“/some_dir/some_file”, &statbuf) == -1) { err(1, "stat"); } if (statbuf.st_size >= MAX_FILE_SIZE) { err(2, "file size"); } if ((fd=open(“/some_dir/some_file”, O_RDONLY)) == -1) { err(3, "open - %s",argv[1]); } Figure 7-4Symbolic linking exploitsReason for its wide spread use in exploitsCreation of symlink is not checked to ensure that the owner of the link has any permissions for the target file, norIs it even necessary that the target file existsThe attacker only needs write permissions to the directory in which symlink is createdFurther complication introduced by the followingSymlink can reference a