On Wed, Apr 24, 2013 at 11:16:39AM -0600, Kyle Wheeler wrote: > So, what is the purpose of the entropy here? If the point is to find > a likely-to-be-unique name for temporary files associated with the > message, wouldn't something like an MD5 or SHA1 sum of the email in > question be sufficient?
NO! I've already explained why. > An attacker might be able to predict the sum with a certain accuracy > if he already has access to the message, but... what exactly are we > protecting against here? There are AT LEAST three relevant classes of attack: - race condition allowing an attacker to take control of the CONTENT of the temporary file, possibly thereby effecting an attack via some other program (e.g. feeding bad data to an attachment MIME handler which allows arbitrary code execution). - DoS by (repeatedly) creating the temporary file that the application is trying to create, preventing it from ever being able to create a safe temporary file - Symlink attack causing the file to point to some other file than the user intended (possibly causing him to overwrite the contents of something important, e.g. /etc/password if it's writable by that user, or $HOME/.ssh/authorized_keys, etc.) There are probably more; I'm pretty knowledgable about this topic, but NOT an expert. To foil all of these, you need to ensure the file name is not predictable, that the range of file names is large enough that the attacker can't create a large portion of the possible values in the time frame of a potential race, and the file needs to be opened securely. You MUST do ALL of these things. There are really two aspects to getting this right: opening the file securely, and providing an adequately random name generator to avoid a collision. We already know how to do the former; what we're discussing now is the latter. If you use anything in the messge store as the source of your randomness, then potentially--and most especially if you use the current message being read, or any part of it, you give the attacker COMPLETE CONTROL over the randomness. Therefore, you GUARANTEE his success. > If the goal is to keep the attacker from DoS'ing the user... That is only PART of the goal. There are much worse outcomes. > let's think about this a little. Very smart people have already thought about this A LOT. There are numerous articles and papers on the topic. If you really want to implement a solution for this that doesn't use the system libraries, you should go read some of them. The conclusion (or one of them) is using untrusted data--e.g. a message supplied by anyone other than the user--as a source of randomness is FAIL. -- 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.
pgpu1vs8jcumG.pgp
Description: PGP signature
