Topic: Do temporary files store sensitive data?

Looking at the source (misc.js and cplglin.js) it appears that GPG is invoked on temporary files created in the local filesystem. Is this actually the case? If so, it would leave the sensitive data (including passphrases) on the disk since I don't see any secure wiping being done on the temporary files before they're deleted. Any information or corrections would be appreciated. Thanks!

Re: Do temporary files store sensitive data?

Yes, and yes it's save your password. But.

The only thnigs is done when you password is on the disk, it's to call Gpg. We save it juste before, and delete it just after.

Here is the code :

putIntoFile(tmpPASS, password); // DON'T MOVE THIS LINE !
        try { runCommand(tmpRun,
                   '' + this.getGPGCommand() + '' +  " " + tmpStdOut +
                   " --quiet --no-tty --no-verbose --status-fd 1 --armor --batch" +
                   " --default-key " + keyID +
                   " --output " + tmpOutput +
                   " --passphrase-file " + tmpPASS + "" +
                   getGPGCommentArgument() + getGPGAgentArgument() +
                   " --clearsign " + tmpInput); } catch (e) { }
        removeFile(tmpPASS);  // DON'T MOVE THIS LINE !

And the file name is random. We done test (with a slow computer / with a error with gpg), and in all case, the password was deleted, and we can't access it. The right are on 600 too.

So don't panic: your password will never be keep on the disk, I thinks he never go more far than the disk's cache...

Re: Do temporary files store sensitive data?

If the passphrase file isn't wiped before deleting it, the passphrase stays written to the physical disk until the sectors it was using get allocated to another file and are overwritten. It would not be hard to write a program that would read through the entire hard disk and try every sequence of bytes as a passphrase with a length between 1 and 100, and it would probably only take a few hours to run depending on the size of the hard disk. I use gpg on my laptop and expect that if it's stolen no one is going to be able to scan the disk for pass-phrases to all my encrypted files and recover them, which would be possible if I used FireGPG on a daily basis and it left my passphrase laying around in unallocated sectors. For desktop computers, it's secure until you give it away to someone else or sell it. Unless you want to spend a lot of time securely wiping your disk. What happens if you have to send your computer in for repair and they swap the disk out? Half the time they'll try to refurbish it and give it to someone else with a new image which isn't large enough to overwrite all the personal data stored on the disk. Lots of places say they wipe old drives before they resell them but don't actually do it.

The proper way to call GnuPG from another program is to use pipes or fifos on gpg's standard input and output file descriptors and write the input data to gpg's stdin, and read its output from stdout directly from the calling program. Additionally, the --passphrase-fd flag tells GnuPG to read the passphrase from another open file descriptor so that nothing sensitive ever touches the disk. It's kind of a pain, and I haven't seen any functions for actually doing that from the Mozilla plugin interfaces, but I'll keep looking and offer a patch if I can write one. It might be possible to do it with named pipes, depending on how they're implemented on Windows and Linux. For instance, if it's not possible to just fork and run GnuPG (I haven't seen anything about forking in the documentation), then gpg would have to be run with input and output redirected to pipes that FireGPG created, and use --passphrase-file to access a named pipe that FireGPG can write to. It would depend on the named pipes not caching data to disk.

If nothing else, it would be good to securely wipe the files before deletion by writing random bytes over the entire length of the file, since that will stop everyone without special hardware or disk control software (and luck). It might be good to provide a notice about this to people who are in a situation where they can't allow any sensitive information to be leaked to the disk, too.

Re: Do temporary files store sensitive data?

Yes, but we will found a solution (pipes can't be used, but the last seem a good idea).

In all case, you use swap, and into swap, there are the posibility that your password are into... (Ok, I you crypted your swap, no)

Re: Do temporary files store sensitive data?

I tried writing some simple code to do the random overwriting, but for some reason Firefox doesn't overwrite the file, instead it creates "File-1" and writes the random data to it, but doesn't seem to overwrite the original file. Here's what I did:

function removeFile(path) {
    var fileobj = Components.classes[NS_LOCALEFILE_CONTRACTID].

    var stream = Components.classes[";1"]
    stream.init(fileobj, WRITE_MODE, WRITE_PERMISSION, 0); // write, no creation or truncation because it should overwrite the existing data

    var randombytes;
    // Create a string of 4096 bytes for speed, Math.random + multiply +
    // floor is almost certainly too slow for large files. Overwriting
    // with repeating random data is sufficient to prevent most data
    // recovery

    for(var i=0;i<4096;i++) randombytes += String.fromCharCode(Math.floor(Math.random()*256));

    var filesize = fileobj.fileSize;

    for(i=0;i<filesize;i+=4096) {
        stream.write(randombytes, randombytes.length);



    try {
    catch (e) {
        // If file dosen't exist

I don't write javascript very much, and this is the first time I've done anything with the Mozilla file and stream libraries, so it may just be a problem with how I wrote it. The alert(fileobj.path) and alert("wait") are in there for debugging. When alert(fileobj.path) runs, it prints /tmp/1182238476247fgpg_tmpFile, but if I look in /tmp I also see /tmp/1182238476247fgpg_tmpFile-1 which actually gets the random bytes written to it, and the original file stays the same. At the alert("wait") line, the -1 file is gone but the original file still has the original data and is not random.

I've tried a couple combinations of values for WRITE_MODE including just 0x02 to open the file write only, since truncating it may deallocate the sectors and the random bytes might get allocated to different ones. I suppose I could write a shell script and batch file that do the secure wiping, but it would require a special utility for Windows and would rely on having dd and /dev/urandom on Linux, which isn't very cross platform. I could also write a C program that would compile on Windows and Linux to do a simple wipe, but I don't know if the project wants to start collecting stuff written in other languages.

Re: Do temporary files store sensitive data?

regarding this and hidden start post: what about using enigmail inter process communication javascript?
from the source:

// ipc.js: Run environment for Javascript CGI

// Global functions available to Javascript CGI:
//   write(arg1, arg2, ...)   : writes to "stdout"
//   writeln(arg1, arg2, ...) : writes to "stdout" with newline
//   getEnv(name)  : return value of environment variable or null string
//   execSh(command) : executes command and returns its stdout (requires ipcserv)

this will be a lot more secure than current implementation.

(btw: is ipc.xpt in your svn repository somehow related?)

Re: Do temporary files store sensitive data?

blivengood -> It's beacause you init a tempory file (so FF use a unique name), see our 'getContent' function for a a stream of a existing file)

Sid77 -> Yes, we're do some scrach to fix the problem, and ipc.xpt is related. But Enigma use complicated functions...

We will secure this system, but the first priority is a standart system for gmail...

(No hstart.exe will needed with ipc, so we can say it's our second priority big_smile)

Re: Do temporary files store sensitive data?


I also think writing passphrase to temporary files is really not secure.
Ipc could be a solution, but it is quite complicated (they are binary components, and you have to provide one different for each platform).

In my opinion, a temporary fix would be to call gpg with arguments --passphrase mypassphrase (instead of writting passphrase to a file and calling --passphrase-file).
I sent a patch to firegpg a few weeks ago but I had no feedbacks. (ok, I also made a few others proposals, and my patch was quite messy, may be that's the reason why it was not included).

main part of it was :

function runChromeCommand(chromePath, args) {
    var ioService = Components.classes[NS_IOSERVICE_CONTRACTID].getService(Components.interfaces.nsIIOService);
   var uri = ioService.newURI(chromePath, null, null);

    var realPath = Cc[";1"].
    var file=Cc[";1"].createInstance(Ci.nsILocalFile);

   var process = Cc[";1"].
    process.init(file);, args, args.length);


const FIREGPG_UNIX_SCRIPT = "chrome://firegpg/content/

var args = [].concat(this.getGPGCommand(), tmpStdOut,
       "--quiet", "--no-use-agent", "--no-tty", "--no-verbose", "--status-fd", "1", "--armor", "--batch",
        "--default-key", keyID,
       "--output", tmpOutput,
       "--passphrase", password,
     "--clearsign", tmpInput);

try { runChromeCommand(FIREGPG_UNIX_SCRIPT, args); } catch (e) { }

It works fine, at least on my linux laptop.

Last edited by arno. (2007-06-30 11:45:48)

Re: Do temporary files store sensitive data?

another option might be to use a use-agent

Re: Do temporary files store sensitive data?

Can't work for Windows users, can't work with special chars.

Re: Do temporary files store sensitive data?

unfortunately, IPC is the only way to go: both using a temp file and --passphrase is insecure, as password can be easily read through the file or with "ps -aux | grep gpg"

Re: Do temporary files store sensitive data?

sid77 wrote:

unfortunately, IPC is the only way to go: both using a temp file and --passphrase is insecure, as password can be easily read through the file or with "ps -aux | grep gpg"

I'm glad you mentioned this I was using an option to send the password for the rdesktop like so

passwd=`cat ~/domainpassword.gpg | gpg2 --decrypt --use-agent`
rdesktop -f -u abbatech\\root -p ${passwd} $* &

So I checked to see if I could see the password from ps. Funny thing though my ps was not showing the results of
`cat ~/domainpassword.gpg | gpg2 --decrypt --use-agent` it was showing XXXXXXXXXX

ps -aux | grep rdesktop
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.7/FAQ
root     15534  0.0  0.1  10200  2588 pts/4    S    13:12   0:00 rdesktop -f -u Username -p XXXXXXXXXXX computer
root     15560  0.0  0.0   3880   656 pts/4    R+   13:22   0:00 grep rdesktop

it should be -ef actually I remember hearing about this somewhere

ps -ef | grep rdesktop
root     15534     1  0 13:12 pts/4    00:00:00 rdesktop -f -u Username -p XXXXXXXXXXX computer
root     15564 15220  0 13:23 pts/4    00:00:00 grep rdesktop

I am kind of puzzled here is my "ps" command intelligent enough to strip this would it also be intelligent  enough to strip
the password from a gpg command.

apparently not, but why. Ok maybe the rdesktop command sends XXXXXXXXX to ps instead of that argument so we would have to talk with the gpg developers. and I think gpg is left in favor of gpg2

Last edited by jeff.sadowski (2007-07-02 20:58:21)