This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] CVE-2015-7547 --- glibc getaddrinfo() stack-based buffer overflow

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

Please feel free to post again for review.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]