From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7422 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 19:07:31 +0200 Message-ID: <55328F53.1070705@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> <55328604.4000705@gmx.de> <20150418163702.GI6817@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 1429376889 19931 80.91.229.3 (18 Apr 2015 17:08:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Apr 2015 17:08:09 +0000 (UTC) Cc: Matt Johnston To: musl@lists.openwall.com Original-X-From: musl-return-7435-gllmg-musl=m.gmane.org@lists.openwall.com Sat Apr 18 19:08:01 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 1YjWDp-0000W7-EI for gllmg-musl@m.gmane.org; Sat, 18 Apr 2015 19:08:01 +0200 Original-Received: (qmail 17701 invoked by uid 550); 18 Apr 2015 17:07:59 -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 17683 invoked from network); 18 Apr 2015 17:07:59 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 In-Reply-To: <20150418163702.GI6817@brightrain.aerifal.cx> X-Provags-ID: V03:K0:fTGwI3u1D67zXff7cnpAu9DIbNtp5GOr9jSfFNnncg5WcEDAkGF YfMdkbWEvaThFzu9EGBQ6aH7LWcOvxtCU2OY8aaQK17g1OrS22+anr7605GLV5kQtoVmOib Mdsl3zOiMIfqm74ydU7JyU7jD4MRuK2AHAfaVmi5pzpgoedCP0A63NXWF8fuVHFjd+henJ8 f377BVFrO9G3oPWGyVpyA== X-UI-Out-Filterresults: notjunk:1; Xref: news.gmane.org gmane.linux.lib.musl.general:7422 Archived-At: On 18.04.2015 18:37, Rich Felker wrote: >> @Rich: I still get DNS error (Mozilla Thunderbird) for >> dalias@libc.org, when tying to send mail :( > > Odd. I just verified that Google's 8.8.8.8 resolves it right, so I > don't know what's wrong, but it seems to be on your end. Let me know > if you find anything that looks like a problem on my side. AFAIK, you use a CNAME as MX, which is resolved on some, but not all systems / programs. You need to add an absolute IP address for your MX, not a CNAME, to be accessible for all. A-record lookup is ok (resolved recursive), but MX lookup fails (doesn't do recursive lookup everywhere). >> On 18.04.2015 17:58, Rich Felker wrote: > Well anything that gets code execution in the dropbear session process > would be able to steal the key still. The only added protection you'd > get is is against heartbleed-type attacks (arbitrary memory read but > no code exeution). ACK, ... isn't that bad, to protect against that kind of key steeling, with a very simple solution, and no need to further code restructuring? IMO it is a quick intermediate solution, until someone may be able to restructure key creation code, still giving the possibility to let dropbear drop root privileges completely (except pty/utmp question). >> 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) > > If this external process is setuid/setgid, I consider that a much > bigger vuln. Just to mention: My statement 'separate process' doesn't included or intended a separate suid/sgid program. > It would have to somehow verify that it's being invoked > by a valid dropbear session process and not some other caller that > just wants to use it to steal keys/forge key negotiations, and you > have all the usual issues with setuid programs having to be defensive > about the state they inherit when invoked. I didn't think of an exec to a separate program, but just fork and let a process for key management run in the back. So a bit simpler to verify authentication of caller, but still somehow required ... or what else did you suggest? > If on the other hand the session process just kept gid=dropbear to > open and reload the key, it wouldn't be so bad. That's it, the key creator part doesn't need root privileges for it's operation either. That is just a combination of the two approaches. Harald