From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 1 11:26:49 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F181D98 for ; Wed, 1 Apr 2015 11:26:49 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 01A45D3D for ; Wed, 1 Apr 2015 11:26:48 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-255-201.lns20.per4.internode.on.net [121.45.255.201]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t31BQYIR024417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 1 Apr 2015 04:26:40 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <551BD5E5.6050404@freebsd.org> Date: Wed, 01 Apr 2015 19:26:29 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Mateusz Guzik , Oliver Pinter , Yue Chen , Benjamin Kaduk , "freebsd-hackers@freebsd.org" , HardenedBSD Core , PaX Team Subject: Re: How to traverse kernel threads? References: <20150321220246.GE14650@dft-labs.eu> <20150321232622.GF14650@dft-labs.eu> <20150327194920.GB18158@dft-labs.eu> <20150330173358.GB9095@dft-labs.eu> In-Reply-To: <20150330173358.GB9095@dft-labs.eu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 11:26:49 -0000 On 3/31/15 1:33 AM, Mateusz Guzik wrote: > > I do not believe this can be implemented reliably without some serious > tinkering around the kernel. Surely I'm not a live patching expert (not > any other kind of expert), but hear my out. > > It seems proposed approach is to move the kernel around and then updated > all relevant pointers in all pages. > > I do not believe this can be done reliably without corrupting data, > unless a major surgery is performed on the kernel. > > Consider: > struct meh { > func_t *m_func; > size_t m_len; > data *m_buf; > }; > > Here we have 'm_func' which needs to be updated, but we don't know if > that's the only pointer so we have to scan the entire struct. But m_buf > can have data which looks like kernel pointers (i.e. matches some kernel > funcs) and how will you know not to modify it? What if this is some sort > of a hack and in fact you *should* modify it? two examples.. in the VFS code it is not unknown for a local stack variable to be initialised to a method pointer and used separately from the structure.. methodp = struct foo->method; { some code } result = methodp(args); also things like network mbufs can (AND DO!) have functions pointers in them. They can contain pointers to their own 'free' routines. so every packet in transit needs to be scanned as well. one could say that all this difficulty will make your success even more amazing :-) > > CTF or some other solutions like that don't help if you just traverse > all allocated buffers since you have no idea what the object you found > really is. > > So, assuming this has to be done in runtime, the only somewhat workable > solution I see would require leaving function entry points at contant > addresses and only insert jumps to new locations. > > This would be a performance hit and would leave a lot of data at > constant addresses, defeating the point to some extent. > > Also runtime relocation of everything definitely has a lot of unknown > unknowns, so all in all I would say this is a non-starter. > > One could consider a different approach where kernel data is randomly > shuffled around with some granularity and relevant symbol relocated > prior to booting. > > This should provide unique enough layout, which paired with big > likelyhood of a kernel panic on first bad exploit attempt may be an > acceptable solution. > > But then the kernel may still have enough info leaks for this to not > matter, so I would not be so eager to implement it. > > That said, what prompted this entire effort? Is there an operating > system which got this to work or what? > >