Security risks using tmpfile() for sensitive data in PHP

Question

What are the primary concerns when storing sensitive data in PHP's temporary directory via tmpfile()? For instance:

1. Could this data be recovered from HDD by a malicious admin?
2. Could the admin easily change the tmp directory to a permanent storage location?
3. Could the data be easily copied to another location during the initial write process?

My web application stores encrypted user data, but I have to encrypt it so that it can be streamed over webdav. Storing a decrypted copy temporarily seems the easiest approach. Otherwise I may have to invent some block based encryption and decrypt data on-the-fly.

Answer 1

1. The data must be assumed to be flushed when it is written to a file. In theory it might stay in the buffers and never be flushed, but you can't rely on that and you have no way to tell if it did. The temporary file location might be a RAM-mounted disk (like tmpfs in Linux), but you probably don't have access to that information and, again, you can't rely on that being the case. The worst-case (and most likely ) scenario is that it is written to the hard disk, in which case anyone with raw disk read privileges, like the admin, could then search through the raw sectors of the hard drive and examine the data. This isn't as hard as it sounds, I've recovered deleted text files before using a simple chaining of the NIX tools dd and grep.

2. I don't think that's an issue. The file created from tmpfile() should be auto-deleted when you close the file, regardless of where it was created. (At least, so says the manual and experience.)

3. Sure. The admin could monitor the temporary directory and makes a copy of any file he sees created. This should be doable at the user-mode level, and it is certainly doable at the driver level (if they wrote a file-stealing driver and put it in the filesystem stack) if they are very dedicated to swiping every temp file.

As a rule of thumb, any data that needs to be encrypted should not be written to a file unencrypted. File contents aren't under your direct control, and unencrypted data needs to be.

Encryption should be possible on-the-fly with standard encryption schemes. It might be a bit more complicated than doing one big encryption call, but it should definitely be possible using any competent encryption library.

Answer 2

The admin can do anything. If the admin is your enemy then you have lost. He can copy your precious files regardless of where you put them; he can even just read the RAM contents of your PHP process directly.

If the admin is your friend, then your next enemies are other people who have some kind of access to the same machine, e.g. normal (non-admin) users of the machine, and/or other PHP scripts running on the same server. PHP's tmpfile relies (at least on Unix-like systems) on the tmpfile() function provided by the OS (actually a libc function). If you use Linux, you are in luck: that specific implementation creates the file with a random name in /tmp and immediately deletes it. As per Unix semantics, the file still exists (it takes some room in the filesystem) but the name is destroyed, forbidding any access from other users.

You might still have to fear other PHP scripts, if these are hostile and the PHP engine is not properly constrained, because these scripts run under the same account than yours (the account at the OS level, i.e. the Unix user which runs the Web server) and thus may access the file from a link in /proc. But that's rather extreme; if distinct people, potentially hostile to each other, can add their own PHP scripts to the same server with no isolation between them, then there is something very wrong in the server structure, and the admin is not doing his job.

Answer 3

1. As a temporary file is the same as a normal file (in the same respects that it is written to the disk, albeit only for a short period), it could still be recovered using a data recovery tool until it is overwritten. As far as I know when the temp file is removed it is just "unlinked", and not securely erased
2. The temp folder is set at an OS level, so in theory they could change the location, but it should still be removed at the end of the scripts execution regardless of the folder
3. As the file exists for the whole duration of the script (or until it is explicitly closed), it's possible that they could watch the directory and copy anything that appears in it. The file should have the owner set to whoever creates it, but as the admin will have root he will have access anyway

To address point 1, you could call srm on the file and explicitly delete it yourself, which should prevent it being recovered. As for point 2 and 3, it's out of your hands unless you yourself can secure the server.

Hope this helps