Date: Tue, 31 Mar 2015 19:51:28 -0400 From: Rich Felker <dalias@...c.org> To: Justin Cormack <justin@...cialbusservice.com> Cc: musl@...ts.openwall.com, busybox <busybox@...ybox.net> Subject: Re: Re: Busybox on musl is affected by CVE-2015-1817 On Wed, Apr 01, 2015 at 12:11:18AM +0100, Justin Cormack wrote: > On 31 March 2015 at 20:07, Denys Vlasenko <vda.linux@...glemail.com> wrote: > > On Mon, Mar 30, 2015 at 7:31 AM, Rich Felker <dalias@...c.org> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.