From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7298 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general,gmane.linux.busybox Subject: Re: Re: Busybox on musl is affected by CVE-2015-1817 Date: Tue, 31 Mar 2015 19:51:28 -0400 Message-ID: <20150331235128.GO6817@brightrain.aerifal.cx> References: <20150330053150.GA484@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 1427845906 10339 80.91.229.3 (31 Mar 2015 23:51:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 31 Mar 2015 23:51:46 +0000 (UTC) Cc: musl@lists.openwall.com, busybox To: Justin Cormack Original-X-From: musl-return-7311-gllmg-musl=m.gmane.org@lists.openwall.com Wed Apr 01 01:51:46 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 1Yd5wf-00022f-7W for gllmg-musl@m.gmane.org; Wed, 01 Apr 2015 01:51:45 +0200 Original-Received: (qmail 9249 invoked by uid 550); 31 Mar 2015 23:51:43 -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 9226 invoked from network); 31 Mar 2015 23:51:43 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7298 gmane.linux.busybox:41100 Archived-At: On Wed, Apr 01, 2015 at 12:11:18AM +0100, Justin Cormack wrote: > On 31 March 2015 at 20:07, Denys Vlasenko wrote: > > On Mon, Mar 30, 2015 at 7:31 AM, Rich Felker wrote: > >> For details on CVE-2015-1817, see: > >> http://www.openwall.com/lists/musl/2015/03/30/1 > >> > >> With musl-linked Busybox installed setuid and ping enabled, exploiting > >> this issue is trivial. > >> > >> While CVE-2015-1817 is certainly musl's fault, there are two changes > >> to Busybox I'd like to propose that would have prevented it from being > >> exploitable: > >> > >> 1. Having setuid utilities like ping obtain the resource they need (in > >> the case of ping, SOCK_RAW) without processing user input at all, > >> then fully dropping root (setuid(getuid())) before doing anything. > >> This has been standard practice for setuid programs since the 90s > >> and it feels bad that busybox is not doing it. > > > > In general this is acceptable, but with this particular case > > and CVE, it wouldn't help. > > > > create_icmp_socket(lsa) needs to know of which address family > > the socket should be: > > > > if (lsa->u.sa.sa_family == AF_INET6) > > sock = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6); > > else > > sock = socket(AF_INET, SOCK_RAW, 1); /* 1 == ICMP */ > > > > This is only known after HOST is parsed. > > And CVE is in DNS resolving code :( > > One advantage if the traditional separation of ping and ping6. I'm against this separation. It relegates IPv6 addresses to second-class status and this kind of treatment is part of the reason why IPv6 support remains spotty. And you don't automatically know in advance if a name is going to resolve to IPv4 or IPv6. > >> 2. Reconsider the rejection of the patch to add SOCK_DGRAM support for > >> ping, which allows it to run without root. > > > > This seems to lead to a significantly larger code. > > Slightly larger code or security holes. Note that in this case it was at the libc level, but this could equally have happened at the busybox level. Also the issue is not exclusive to musl even at the libc level. I seem to recall there being a few vulns in glibc's getaddrinfo over the past couple years which may also have been affected. > Is it really that much bigger? I don't think so. Rich