Received: (at submit) by bugs.debian.org; 1 Feb 2000 22:23:33 +0000 Received: (qmail 6686 invoked from network); 1 Feb 2000 22:23:28 -0000 Received: from noordeinde-39.denhaag.dataweb.nl (HELO this.is.my.net) (postfix@193.78.237.158) by master.debian.org with SMTP; 1 Feb 2000 22:23:28 -0000 Received: by this.is.my.net (Postfix, from userid 1000) id 36DDCC38DD; Wed, 2 Feb 2000 01:32:13 +0100 (CET) Date: Wed, 2 Feb 2000 01:32:12 +0100 From: Guido Witmond To: submit@bugs.debian.org Subject: PGP5i has temp-file problems Message-ID: <20000202013212.A818@dataweb.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i Package: pgp5i Version 5.0-3 Severity: normal The pgpk program creates a temporary file with the name ~/.pgp/pubring.pg0 when operating on the public key ring. The problems encountered: 1) it ignores any files and symlimks and happily overwrites any file with this name. Potential damage: any file that can be access by the user can be corrupted. 2) it does not lock the temp file for concurrent access, leading to race conditions during later filename shuffling. It might lead to loss of service or (speculating) corruption of the public keyring. A busy server and many processess accessing the keyfile might raise the chance of this above 'neglectable'. Ad 1) this guido 23:45 ~/.pgp > date > t this guido 23:46 ~/.pgp > ln -s t pubring.pg0 this guido 23:46 ~/.pgp > ls -l total 427 -rw-r--r-- 1 guido users 51 Apr 28 1996 config.txt -rw-r--r-- 1 guido users 51 Feb 1 22:18 pgp.cfg -rw------- 1 guido users 139817 Feb 1 23:26 pubring.bak lrwxrwxrwx 1 guido users 1 Feb 1 23:46 pubring.pg0 -> t -rw------- 1 guido users 141164 Feb 24 1999 pubring.pgp -rw------- 1 guido users 139817 Feb 1 23:45 pubring.pkr -rw------- 1 guido users 512 Feb 1 23:45 randseed.bin -rw------- 1 guido users 1061 Apr 4 1997 secring.SAVE -rw------- 1 guido users 1113 Feb 1 22:18 secring.bak -rw------- 1 guido users 1113 Jan 14 1999 secring.pgp -rw------- 1 guido users 1113 Feb 1 22:26 secring.skr -rw-r--r-- 1 guido users 29 Feb 1 23:46 t this guido 23:46 ~/.pgp > cat t Tue Feb 1 23:46:14 CET 2000 this guido 23:46 ~/.pgp > pgpk -xa witmond -o witm.asc this guido 23:46 ~/.pgp > ls -l total 568 -rw-r--r-- 1 guido users 51 Apr 28 1996 config.txt -rw-r--r-- 1 guido users 51 Feb 1 22:18 pgp.cfg -rw------- 1 guido users 139817 Feb 1 23:45 pubring.bak -rw------- 1 guido users 141164 Feb 24 1999 pubring.pgp -rw------- 1 guido users 139817 Feb 1 23:46 pubring.pkr -rw------- 1 guido users 512 Feb 1 23:46 randseed.bin -rw------- 1 guido users 1061 Apr 4 1997 secring.SAVE -rw------- 1 guido users 1113 Feb 1 22:18 secring.bak -rw------- 1 guido users 1113 Jan 14 1999 secring.pgp -rw------- 1 guido users 1113 Feb 1 22:26 secring.skr -rw-r--r-- 1 guido users 139817 Feb 1 23:46 t -rw------- 1 guido users 3236 Feb 1 23:46 witm.asc this guido 23:47 ~/.pgp > cmp t pubring.pkr this guido 23:47 ~/.pgp > Ad 2) $ strace pgpk -xa witmond -o witmond.asc [tracing until after this point] open("/home/guido/.pgp/pubring.pg0", O_RDWR|O_CREAT|O_TRUNC, 0666) = 6 and while copying the entire .pkr into .pg0 a second instance of pgpk also execute this open statement above, thereby truncating the work of the first process. The first process will do a: rmdir("/home/guido/.pgp/pubring.bak") = -1 ENOTDIR (Not a directory) unlink("/home/guido/.pgp/pubring.bak") = 0 rename("/home/guido/.pgp/pubring.pkr", "/home/guido/.pgp/pubring.bak") = 0 umask(077) = 022 open("/home/guido/.pgp/pubring.pkr", O_RDWR|O_CREAT|O_TRUNC, 0666) = 5 But as part of the .pg0 file is zeroed by the second process it will lead to: close(5) = 0 munmap(0x40015000, 4096) = 0 rmdir("/home/guido/.pgp/pubring.bak") = -1 ENOTDIR (Not a directory) unlink("/home/guido/.pgp/pubring.bak") = 0 rename("/home/guido/.pgp/pubring.pkr", "/home/guido/.pgp/pubring.bak") = 0 umask(077) = 022 open("/home/guido/.pgp/pubring.pkr", O_RDWR|O_CREAT|O_TRUNC, 0666) = 5 and later on it will detect it somehow: read(6, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 409 6 write(2, "ASSERTION FAILED at pgpFileDB.c "..., 66ASSERTION FAILED at pgpFileDB. c line 129: (rdb->rfile) not true ) = 66 close(6) = 0 munmap(0x40016000, 4096) = 0 rmdir("/home/guido/.pgp/pubring.pg0") = -1 ENOTDIR (Not a directory) unlink("/home/guido/.pgp/pubring.pg0") = 0 close(5) = 0 munmap(0x40015000, 4096) = 0 close(4) = 0 munmap(0x40014000, 4096) = 0 write(2, "Unable to open keyring: ", 25Unable to open keyring: ) = 25 write(2, "Bad data found where key\n", 25Bad data found where key ) = 25 Although it has restored the public key ring it has not performed the requested key export operation. Why it needs to copy my keyring twice just to _export_ a key puzzles me. As the fact that is reads the secring.skr file and updates the randseed.bin. Kind regards, Guido Witmond. (guido@debian.org)