From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7420 Path: news.gmane.org!not-for-mail From: Harald Becker 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 18:27:48 +0200 Message-ID: <55328604.4000705@gmx.de> 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> <20150418155845.GH6817@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1429374493 17156 80.91.229.3 (18 Apr 2015 16:28:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Apr 2015 16:28:13 +0000 (UTC) Cc: Matt Johnston To: musl@lists.openwall.com Original-X-From: musl-return-7433-gllmg-musl=m.gmane.org@lists.openwall.com Sat Apr 18 18:28:10 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 1YjVbG-0007ou-4l for gllmg-musl@m.gmane.org; Sat, 18 Apr 2015 18:28:10 +0200 Original-Received: (qmail 28337 invoked by uid 550); 18 Apr 2015 16:28:08 -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 28309 invoked from network); 18 Apr 2015 16:28:04 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 In-Reply-To: <20150418155845.GH6817@brightrain.aerifal.cx> X-Provags-ID: V03:K0:l+gfYrhuP4vH+IhDbZ71kQURm2IhmniF67X4PN8mhKxaPDB+5Hq IRPe3Q6BME14PcWSwgC6d8atBaflRqOqxGAnArslQv3vM0VI9h5nJQIznLOL/mSl89Fg+X4 oFyQhpp/V07QbnWCD/rddTjqqWqLxbh+QPOaZGC5tkSLuJp/P2xJ1v8HIxXhqBTQQ+mSI40 Vqts6NcpQtPaz7IeBn+VQ== X-UI-Out-Filterresults: notjunk:1; Xref: news.gmane.org gmane.linux.lib.musl.general:7420 Archived-At: Hi ! @Rich: I still get DNS error (Mozilla Thunderbird) for dalias@libc.org, when tying to send mail :( On 18.04.2015 17:58, Rich Felker wrote: > 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. As far as I understand it, the question was, *not to have* the key hanging around in memory, but still have access without requirement to keep root privileges. My suggestion is to solve this, with a very simple and easy to implement solution. I consider it a slight increased security, as the dropbear process can drop root privileges (and has to do so), but still has access to the host keys. > 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. ACK, as told it's intention is a simple solution to give dropbear access to the host keys without letting them hang in memory all the time. > 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. ACK, much better, but this would need major restructuring, wouldn't it? So consider my suggestion a simpler to implement solution, in between having full root privileges or hanging keys in memory, and an external process to do the rekey steps (in addition: with the possibility to let that process use the dropbear group and not root to access keys - even better than let that process hang around as root) Harald