Date: Wed, 30 Jan 2013 11:51:27 -0500 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: [PATCH] Add support for mkostemp, mkstemps and mkostemps On Wed, Jan 30, 2013 at 02:45:37PM +0100, Szabolcs Nagy wrote: > * Hardy Falk <hardy.falk@...boo.com> [2013-01-30 08:59:51 +0100]: > > Am 30.01.2013 08:21, schrieb Rich Felker: > > >On Tue, Jan 29, 2013 at 06:16:11PM -0500, Anthony G. Basile wrote: > > >>>implement, but the random name generator definitely needs a better > > >>>algorithm. I just adopted what was already there, but its not good > > >>>enough. > > >>> > > You should try "shr3" by George Marsaglia (rip) > > no, we dont need a prng there, we get new entropy > at each try from the clock source > > the statistical quality may be improved a bit with > different hashing of the time and addresses, but > it is reasonable now > > for retries the iteration count and the previous > rand could be used as well, but that's a rare case Right now, and attacker who just wants to drastically slow down a program can create every name in a large time window around the current time. Better use of the stack address in generating the filenames could prevent knowing the set of output filenames for a range of times without knowing the stack address in the program being attacked. In fact, I'm a little bit worried that the current approach discloses too much information about the stack address to an attacker. If nothing else, I think some shuffling should be done so that the (typically more valuable) high bits of the stack address are matched with the low (least predictable) bits of the clock. Obviously cryptographic-quality hashes would be a solution, but I don't think anybody wants that much bloat in mkstemp, etc... > more significant improvement can be done by larger > set of names and better entropy source The theoretical bound on the space (6 X's to work with) is slightly under 48 bits (no nulls or slashes), but that assumes you're okay with inserting control characters, shell-special characters, malformed utf-8, etc. I would say most of these are very bad. Other implementations probably use 36 bits or slightly less (base64 perhaps modified base64). I could see it being feasible to increase this slightly and maybe even get up to ~40 bit space using part of the UTF-8 space, but I'm not sure users would like all sorts of random characters in filenames. It would definitely bog down your file manager loading all those fonts to view /tmp.. :-) > the entropy source is mostly problematic on embedded > systems with bad clock, but there is probably no > good source at all there Are you sure this is an issue? IMO it's the kernel's responsibility to give a good clock value however it can. IIRC even mips has a cpu counter or something that could be used to compensate for bad clock hardware, so it seems like a kernel failing if clock_gettime has bad resolution. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.