On Fri, Apr 26, 2013 at 06:52:55PM +0100, Ian Collier wrote: > Opening the file with O_CREAT|O_EXCL is a solid defense against the > first two attacks in almost all common cases except when the temp > filesystem is mounted over NFSv2.
That's right, but this is why your TEMP_DIR shouldn't ever be on NFS. Or at least, when NFS is NFS < v3. > The open questions as far as I'm concerned are: > > - what does the OS's mkstemp guarantee about randomness; The spec guarantees nothing; but in practice implementations are better than that. The reality is, if you care about security, you're not using an older system, you're not using NFSv2, and none of these issues affect you. If that's not the case, it's really your fault (and your problem). Again, it comes down to what platforms are (or should be) considered supported for Mutt. > - what does it guarantee about race conditions on NFSv2, and Nothing. > - is mkstemp followed by link any safer than mktemp followed by O_EXCL? No, but you can't link() a file that doesn't already exist, so you need to have opened the file securely in the first place. The discussion regarding the O_EXCL race in the man page describes how link() can be used safely to create a *LOCK FILE*; it is not adequate for opening a secure temporary file. The assumption is that in your lock file construct, the contents of the lock file are not interesting. With a temporary file, they are. > I therefore conclude that there is a large class of systems on which > mktemp et al do not use the best source of randomness available to them > unless you think the CPU's time stamp counter is difficult enough to > predict. The hardware clock is sufficient... when it is. In other words, on systems which have a clock resolution that is actually microseconds, it's fine. This should cover most modern systems. On systems where the resolution is actually only 1/60s, it's not. Though, even that is better than the suggestion to use the current e-mail as a source of randomness... but just barely. Using /dev/urandom on systems that have it isn't without its own problems... if your system doesn't have enough entropy, reading from /dev/urandom will block until it does. An attacker can drain all the entropy and issue a very large read, which will cause it to block essentially indefinitely. I'm telling you, this is a very hard problem. Solving this problem in a manner that's both good enough and portable is extremely difficult; it may even turn out to be impossible. You basically have to trust that the people who implemented your system did the best they could on your particular platform. The system should do its best to find a unique filename, to avoid the DoS to the extent that it's possible. BUT, it should expect to fail; if it fails repeatedly, the application should complain very loudly and warn you that you may be under attack, so you can go investigate, and find/fire/beat/arrest the attacker. As long as you do that, you're OK. And again, if you create a locked down, randomly named directory at application start time, and use that for all of your temporary files, you greatly minimize the risk of any of this being an issue, even on systems where it might otherwise be... -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
pgplYGxIzBsJL.pgp
Description: PGP signature
