I am taking a security class. The class notes say that an attacker can observe a pattern in temp file names and then make their own temp file to compromise a program. They say that if a temp file is made using a process ID, an attacker could create a symbolic link to a password file with a tripwire process ID so as to make the tripwire use the password file a temp file.
How could attacker use temp files to compromise a password file? Or to otherwise exploit a system?
The first thing to consider is what is the purpose of the temp file.
If the temp is outputting useful information, an attacker could use this to glean information about the functionality of the programs, settings, error messages, etc (depending on the output). The attacker may be able to have a malicious program occasionally scan such files looking for certain patterns to then use in attack logic.
At the same time, if the temp file is going to be read in, you can change the input logic of the legitimate program which is not tightly locked down. For example, if the temp file is going to be read in for the purposes of eval() or running a system() execution you can then make the program do something its privileges will allow on the system to do, that are not expected.
Instead of modifying the temp file which will be read in, it may be possible to create a symbolic link to another file that you as a user cannot access but that the application may have privileges to read. If the program prints out the temp file, you could expose it that way. It sounds like the attack being described in a privilege escalation, not a direct change to the password file.
Code Project: Security Tips for Temporary File Usage in Applications
If the attacker knows where the application creates its temporary files and can guess the name of the next temporary file, the following attack can be realized:
- Attacker will put a symbolic link at the temporary file location.
- The attacker will link the symbolic link to a privileged file.
- Now, the application will unknowingly write to the privileged file instead of writing to the file in the temp directory.
There is also a CWE (CWE-377: Insecure Temporary File) for this, worth the read as well as some of the related instances:
If an attacker pre-creates the file with relaxed access permissions, then data stored in the temporary file by the application may be accessed, modified or corrupted by an attacker. On Unix based systems an even more insidious attack is possible if the attacker pre-creates the file as a link to another important file. Then, if the application truncates or writes data to the file, it may unwittingly perform damaging operations for the attacker. This is an especially serious threat if the program operates with elevated permissions.
The possibility of this attack is not something that is inevitable in the use of temp files. It stems from an insecure implementation of temp files.
For instance, on a Unix system, a hole can be opened if the temporary file directory has incorrect permissions. The /tmp directory is shared by users, and so everyone has write permission to the directory itself (to be able to create files). But a special "sticky bit" permission is applied which prevents users from being able to delete files which they do not own. If that permission bit is missing, then it is possible for a malicious process to create a race condition attack: it notices that a temporary file has just been created, and, before the owning process can use it, it deletes the file and replaces it with its own. (Applications could check the ownership and permissions of the temp file they have just opened, but probably few, if any, bother, because programs are written to trust that the temporary directory is correctly configured.)
If a temporary file is created with incorrect permissions, then it can be accessed and tampered with. Programs that use temporary files must create them with the appropriate permissions. This means that certain highly platform-independent file manipulation functions cannot be used. For instance if we use the C function fopen to create a temporary file, we have a security hole, because fopen does not have any parameters to control what permissions the file will have. On a Unix-like system, it will create a file with liberal permissions (minus only those permissions removed by umask). Platform-specific library functions should be used for creating and opening temporary files.
A program, when it creates a temporary file, always checks whether that file does not exist already. However, this check has to be atomic, otherwise there is a race condition between checking that the file does not exist and opening/creating the file. That race condition is not fixed by correct permissions on the temporary directory. It is fixed by using an atomic operation for creating the file. On Unix, the O_EXCL flag is used in addition to O_CREAT to ask the operating system to fail the open call if the file already exists, otherwise to create it. A potential pitall here is hosting the temporary file directory on some network filesystem which does not honor the atomic semantics of O_EXCL.
Of course, temporary files are not protected against attack from the same security context. (At least, not without the implementation of fine-grained security policies in the OS.) If a malicious program runs as user joe aleady, then that program can attack temp files created by programs that are running as user joe. To prevent that sort of thing, you need a security scheme which is finer grained than simple account-based security domains. For instance a security system with rules such as: "only executable /bin/foo is allowed to access any filesystem object whose path matches the pattern /tmp/foo*".
Many programs implicitly trust that what they write into their temp files is what will still be there a few milliseconds or seconds or minutes later. If you can predict what name a temp file will have then you have a better chance of catching the file in between its creation and its contents being read back out, and you can write malicious data into the file.
