This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] CVE-2015-7547 --- glibc getaddrinfo() stack-based buffer overflow
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Nix <nix at esperi dot org dot uk>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 17 Feb 2016 16:43:51 -0500
- Subject: Re: [PATCH] CVE-2015-7547 --- glibc getaddrinfo() stack-based buffer overflow
- Authentication-results: sourceware.org; auth=none
- References: <56C32C20 dot 1070006 at redhat dot com> <56C32DB0 dot 7090409 at redhat dot com> <87k2m3owqt dot fsf at esperi dot org dot uk>
On 02/17/2016 04:25 PM, Nix wrote:
> On 16 Feb 2016, Carlos O'Donell told this:
>
>> - Via getaddrinfo with family AF_UNSPEC or AF_INET6 the overflowed
>> buffer is located on the stack via alloca (a 2048 byte fixed size
>> buffer for DNS responses).
>>
>> - At most 65535 bytes (MAX_PACKET) may be written to the alloca buffer
>> of 2048 bytes. Overflowing bytes are entirely under the control of the
>> attacker and are the result of a crafted DNS response.
>
> It seems plausible to me that this could have been ameliorated somewhat
> by -fstack-protecting glibc. I think I might revive my stack-protection
> patch in the ancient bug 7065, split it up properly and describe the
> pieces clearly, and ask for help with the one remaining bug in it (a
> crash in PI mutex unlocking which I have no understanding of whatsoever,
> but which is clearly caused or provoked by the patch). I just forward-
> ported it to 2.22 and it was more or less effortless, with its single
> known bug unchanged: if I were to forward-port it to the trunk, would
> people be amenable to suggesting how I could fix it so it isn't buggy
> and is perhaps even maintainable, or is the very idea of
> stack-protecting glibc still anathema?
>
> The patch does not -fstack-protect the dynamic loader, because that's
> crazy as a first try, though it does modify glibc startup so that
> statically linked programs are protected immediately, because it has to.
> But it does -fstack-protector{-all,-strong} everything else, including
> libc and the NSS libraries.
>
> It's been running on my x86-32 firewall for about eight years now
> without incident: I originally wrote it against 2.13! It seems like it's
> time to stop sitting on it out of fear of libc-alpha and actually *post*
> it for everyone to laugh at and hopefully try to improve...
It's a very good idea. I think we should stack protect libresolv, libdl,
nscd, etc, and we do already. Extending that is only going to be a good
thing.
Please feel free to post again for review.
Cheers,
Carlos.