From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 24 13:10:14 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 698F6106566B for ; Fri, 24 Jul 2009 13:10:14 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by mx1.freebsd.org (Postfix) with ESMTP id EADBC8FC1E for ; Fri, 24 Jul 2009 13:10:12 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 99FF794013F; Fri, 24 Jul 2009 15:10:07 +0200 (CEST) Received: from endor.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp1-g21.free.fr (Postfix) with ESMTP id B89AC9400ED; Fri, 24 Jul 2009 15:10:04 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 8A62433E61; Fri, 24 Jul 2009 13:09:28 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 6E99BA14E1; Fri, 24 Jul 2009 13:09:28 +0000 (UTC) Date: Fri, 24 Jul 2009 15:09:28 +0200 From: Jeremie Le Hen To: Ed Schouten Message-ID: <20090724130928.GJ54986@felucia.tataz.chchile.org> References: <20090508214117.GY58540@hoeg.nl> <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> <20090724073451.GH54986@felucia.tataz.chchile.org> <20090724081842.GF55190@deviant.kiev.zoral.com.ua> <20090724115404.GI54986@felucia.tataz.chchile.org> <20090724115649.GV68469@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090724115649.GV68469@hoeg.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kostik Belousov , FreeBSD Hackers , Jeremie Le Hen Subject: Re: concurrent sysctl implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 13:10:14 -0000 On Fri, Jul 24, 2009 at 01:56:49PM +0200, Ed Schouten wrote: > * Jeremie Le Hen wrote: > > On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote: > > > On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: > > > > Hi Ed, > > > > > > > > Sorry for the late reply. > > > > > > > > On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: > > > > > We probably could. I think I discussed this with Robert Watson some time > > > > > ago and we could use things like ELF hints. But still, that doesn't > > > > > prevent us from reaching this limitation later on. > > > > > > > > Can you elaborate a little? Are you talking about elf-hints.h? > > > > I don't see where we can get randomness from it. > > > > > > The thing is called ELF auxillary information vector. It is used to > > > supply some useful information for interpreter from the kernel, > > > see include/machine/elf.h for AT_* entries. > > > > Ah ok, so the idea is to generate a new hint, for instance AT_RANDOM, > > generated at link time, that will be used to fill the canary at exec(2) > > time? > > Very short answer: yes! Ok thanks. But this would make stack protection useless for local attacks on suid binaries that are world-readable since the attacker could read the ELF aux vector and compute the canary. Upon each invocation, the canary would stay the same which makes the repeat-until-success attack feasible for daemons that are automatically respawned. This saves one syscall per exec(2) but reduce security for the two cases described above. In the performance test I've run with and without -fstack-protector to build world, I saw only around 1 percent penalty. I must admit this was on a UP system which wasn't loaded though. I know that the sysctl system may be redesigned in the future to allow more concurrency. Is it something that could prevent from changing the way the canary is initialized? Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org >