|
Message-ID: <20130130192233.GP20323@brightrain.aerifal.cx> Date: Wed, 30 Jan 2013 14:22:33 -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 08:12:58PM +0100, Szabolcs Nagy wrote: > * Rich Felker <dalias@...ifal.cx> [2013-01-30 11:51:27 -0500]: > > 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. > > void __randname(char *p) > { > struct timespec ts; > unsigned long r; > int i; > > clock_gettime(CLOCK_REALTIME, &ts); > r = ts.tv_nsec*65537 ^ (uintptr_t)&ts / 16 + (uintptr_t)p; > for (i=0; i<6; i++, r>>=5) > p[i] = 'A'+(r&15)+(r&16)*2; > } > > this uses 30bits of r and mixes the random low bits of nsec > into the high bits Keep in mind it might be bits 8-15 that are most valuable with ASLR (assuming the randomization only adjusts by small amounts and not so much to waste lots of address space). I think this needs a little bit more consideration. > > > more significant improvement can be done by larger > > > set of names and better entropy source > > > > 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 > > <= 36bits is probably ok You mean >=36? Or..? 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.