Re: Re: Busybox on musl is affected by CVE-2015-1817

[Rich Felker <dalias@libc.org>]

On Wed, Apr 01, 2015 at 12:11:18AM +0100, Justin Cormack wrote:
> On 31 March 2015 at 20:07, Denys Vlasenko <vda.linux@googlemail.com> wrote:
> > On Mon, Mar 30, 2015 at 7:31 AM, Rich Felker <dalias@libc.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