From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2703 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] Add support for mkostemp, mkstemps and mkostemps Date: Wed, 30 Jan 2013 20:12:58 +0100 Message-ID: <20130130191257.GH6181@port70.net> References: <1359349583-3643-1-git-send-email-basile@opensource.dyc.edu> <20130128093755.GI10600@port70.net> <5108583B.4080002@opensource.dyc.edu> <20130130072108.GN20323@brightrain.aerifal.cx> <5108D2F7.3050207@qomboo.com> <20130130134537.GF6181@port70.net> <20130130165127.GO20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1359573188 20184 80.91.229.3 (30 Jan 2013 19:13:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Jan 2013 19:13:08 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2704-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 30 20:13:29 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1U0d68-0000je-PV for gllmg-musl@plane.gmane.org; Wed, 30 Jan 2013 20:13:28 +0100 Original-Received: (qmail 11526 invoked by uid 550); 30 Jan 2013 19:13:09 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 11514 invoked from network); 30 Jan 2013 19:13:09 -0000 Content-Disposition: inline In-Reply-To: <20130130165127.GO20323@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2703 Archived-At: * Rich Felker [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 using ^ as i guess that way it's harder to do useful arithmetics with known r values > > 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 > > 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 it was just a guess, iirc there are devices with low resolution clock (lower than nanoseconds) which can mean short period of the last few bits of nsec but i dont know how this works > 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