From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7416 Path: news.gmane.org!not-for-mail From: Matt Johnston 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 21:32:02 +0800 Message-ID: <20150418133202.GG17615@ucc.gu.uwa.edu.au> References: <20150417131008.GE17615@ucc.gu.uwa.edu.au> <20150417172327.GB6817@brightrain.aerifal.cx> <20150417180325.GC6817@brightrain.aerifal.cx> <20150417180907.GA26856@openwall.com> 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 1429363944 22811 80.91.229.3 (18 Apr 2015 13:32:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Apr 2015 13:32:24 +0000 (UTC) Cc: Rich Felker To: musl@lists.openwall.com Original-X-From: musl-return-7429-gllmg-musl=m.gmane.org@lists.openwall.com Sat Apr 18 15:32:20 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 1YjSr6-0002wW-Er for gllmg-musl@m.gmane.org; Sat, 18 Apr 2015 15:32:20 +0200 Original-Received: (qmail 22143 invoked by uid 550); 18 Apr 2015 13:32:18 -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 22123 invoked from network); 18 Apr 2015 13:32:17 -0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CkBABeXDJV/8+AX4JdynaHUgKBZxMBAQEBAQEBfYQgAQEBAwE6PwULCxgJGgsPBRiIZwjHZAEBAQcBAQEBAR2LKYE7gnZLBxaEFwWLPZAOlSMighIMGYFJgyYBAQE X-IPAS-Result: A2CkBABeXDJV/8+AX4JdynaHUgKBZxMBAQEBAQEBfYQgAQEBAwE6PwULCxgJGgsPBRiIZwjHZAEBAQcBAQEBAR2LKYE7gnZLBxaEFwWLPZAOlSMighIMGYFJgyYBAQE X-IronPort-AV: E=Sophos;i="5.11,599,1422892800"; d="scan'208";a="135882233" Content-Disposition: inline In-Reply-To: <20150417180907.GA26856@openwall.com> X-snowman: =?utf-8?B?4piD?= User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:7416 Archived-At: > On Fri, Apr 17, 2015 at 02:03:25PM -0400, Rich Felker wrote: > > On Fri, Apr 17, 2015 at 01:23:27PM -0400, Rich Felker wrote: > > > And wow, this is an utter mess. Not only does dropbear fail to drop > > > root before processing forwards; it NEVER drops root at all. The [snip] > > > Is there any reason for not performing the setgroups/setgid/setuid > > > immediately after authentication succeeds? Have you looked at whether > > > it would be easy to patch that in? > > > > Simply copying/moving the code from svr-chansession.c's execchild to > > svr-auth.c's send_msg_userauth_success seems to fix the entire issue. > > I had to disable the (useless on systems with proper pty support) > > chown/chmod for the pty, but otherwise it seems to be working fine. > > I guess changes like these should be upstream'ed. Matt? Hi Rich, Thanks for the suggestion. When the code was originally written quite a few systems had to use older pty methods though that has improved now, it is worth revisiting. Some systems still require --disable-openpty (old uClibc or built with strange configurations, I think). utmp/wtmp logs require privileges to write, Dropbear could add utmp group on systems using that (not sure how widespread it is). The server hostkey will remain in process memory since it's required for rekeying - not as bad as root code execution though. Proper separation with a privileged supervisor is on my todo list, I'll have a look how feasible a simpler approach is. > > musl's network-facing DNS code seems a bit precarious with > > pointer arithmetic? > > Which code are you talking about? There was a previous > problem with > dn_expand, which is the main function that comes to mind for > me, and > the code was fixed and heavily reviewed at the time. Yes, dn_expand was what I was thinking of - at the time I looked at the fix and it seemed like difficult code to reason about. Overall the code style of musl seems quite nice, I guess the parsing type code is just fairly terse. The masking with ip[i&7]=0 in the recent fix was a bit non-obvious without looking at the commit message - makes sense as a safety mechanism. Cheers, Matt