From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7419 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] Date: Sat, 18 Apr 2015 11:58:45 -0400 Message-ID: <20150418155845.GH6817@brightrain.aerifal.cx> References: <20150417131008.GE17615@ucc.gu.uwa.edu.au> <20150417172327.GB6817@brightrain.aerifal.cx> <20150417180325.GC6817@brightrain.aerifal.cx> <20150417180907.GA26856@openwall.com> <20150418133202.GG17615@ucc.gu.uwa.edu.au> <20150418152542.GG6817@brightrain.aerifal.cx> <55327D1F.5070807@gmx.de> 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 1429372744 23424 80.91.229.3 (18 Apr 2015 15:59:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Apr 2015 15:59:04 +0000 (UTC) Cc: musl@lists.openwall.com, Matt Johnston To: Harald Becker Original-X-From: musl-return-7432-gllmg-musl=m.gmane.org@lists.openwall.com Sat Apr 18 17:59:03 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YjV94-0005Oc-Kz for gllmg-musl@m.gmane.org; Sat, 18 Apr 2015 17:59:02 +0200 Original-Received: (qmail 17816 invoked by uid 550); 18 Apr 2015 15:59:01 -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 17798 invoked from network); 18 Apr 2015 15:59:00 -0000 Content-Disposition: inline In-Reply-To: <55327D1F.5070807@gmx.de> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7419 Archived-At: On Sat, Apr 18, 2015 at 05:49:51PM +0200, Harald Becker wrote: > On 18.04.2015 17:25, Rich Felker wrote: > >>The server hostkey will remain in process > >>memory since it's required for rekeying - not as bad as root > >>code execution though. > > > >Ugly. I don't see how this can be solved without a more advanced > >privsep model. I agree it's lower-severity though. > > IMO you may put the host keys in a file readable (not writable) with > a dropbear group, and only using that group for dropbear (no other > users or programs using that group). So you may read the keys even > if not root, if you add this dropbear group to setgroups (not > setgid) before dropping root privileges. The key is already in memory. A design like the above would not significantly improve security (except for heartbleed type issues); it would be just like the situation now where the key is already in memory. To make it more secure, the session process would not have any access to the key and would have to communicate with an existing privileged process to rekey. Rich