From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7297 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general,gmane.linux.busybox Subject: Re: Busybox on musl is affected by CVE-2015-1817 Date: Tue, 31 Mar 2015 19:48:10 -0400 Message-ID: <20150331234810.GN6817@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 1427845724 7669 80.91.229.3 (31 Mar 2015 23:48:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 31 Mar 2015 23:48:44 +0000 (UTC) Cc: busybox , musl To: Denys Vlasenko Original-X-From: musl-return-7310-gllmg-musl=m.gmane.org@lists.openwall.com Wed Apr 01 01:48:35 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 1Yd5tX-0007fK-Ha for gllmg-musl@m.gmane.org; Wed, 01 Apr 2015 01:48:31 +0200 Original-Received: (qmail 6108 invoked by uid 550); 31 Mar 2015 23:48:30 -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 6058 invoked from network); 31 Mar 2015 23:48:25 -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:7297 gmane.linux.busybox:41099 Archived-At: On Tue, Mar 31, 2015 at 09:07:19PM +0200, 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. Sure it does. > 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 :( The solution is simple: create both raw sockets and close the one you don't need later. There's probably also a way to use the AF_INET6 raw socket or IPv4 ping, but I don't know right off. > > 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. I don't recall the exact amount, but given that busybox's suid framework is not taking any precautions to mitigate the risks of suid (not to mention that eliminating all suids is a goal of some security-conscious systems integrators) I think it would be worth it even if it doubled the size of the ping utility (which it does not). Rich