From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7404 Path: news.gmane.org!not-for-mail From: Solar Designer 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: Fri, 17 Apr 2015 21:09:07 +0300 Message-ID: <20150417180907.GA26856@openwall.com> References: <20150417131008.GE17615@ucc.gu.uwa.edu.au> <20150417172327.GB6817@brightrain.aerifal.cx> <20150417180325.GC6817@brightrain.aerifal.cx> 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 1429294157 10813 80.91.229.3 (17 Apr 2015 18:09:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Apr 2015 18:09:17 +0000 (UTC) Cc: Matt Johnston To: musl@lists.openwall.com Original-X-From: musl-return-7417-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 17 20:09:16 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 1YjAhW-0004Jj-3l for gllmg-musl@m.gmane.org; Fri, 17 Apr 2015 20:09:14 +0200 Original-Received: (qmail 13439 invoked by uid 550); 17 Apr 2015 18:09:12 -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 13420 invoked from network); 17 Apr 2015 18:09:12 -0000 Content-Disposition: inline In-Reply-To: <20150417180325.GC6817@brightrain.aerifal.cx> User-Agent: Mutt/1.4.2.3i Xref: news.gmane.org gmane.linux.lib.musl.general:7404 Archived-At: Rich, You dropped the copy to Matt on the previous reply. I've re-added it. 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 > > user's session remains running as root for its full lifetime. Aside > > from being a huge risk, it also allows users to bypass uid-based > > firewall rules via port forwarding; for example, a rule that forbids > > normal users from making outgoing connections on port 25 would not be > > honored. > > > > 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? Thanks, Alexander