This is the mail archive of the libc-alpha@sourceware.org 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 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...


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