[dns-operations] CVE-2015-7547: glibc getaddrinfo buffer overflow

Mukund Sivaraman muks at isc.org
Tue Feb 23 20:09:28 UTC 2016

On Tue, Feb 23, 2016 at 02:21:15PM -0500, Robert Edmonds wrote:
>     The attacks do not need to be garbage that could never survive a DNS
>     cache, as they are in the Google PoC. It’s perfectly legal to have
>     large A and AAAA responses that are both cache-compatible and
>     corrupt client memory. I have this working well.

I haven't read the glibc code to see how it is vulnerable (i.e., the
sequence of events that lead to the buffer overflow). From the
proof-of-concept code, it seems that a truncated message causes the
retry (the 2nd query explained in the mail by Carlos O'Donell).

Assuming the 2nd message overflows on the stack and overwrites the
return address suitably,

(1) A CNAME chain could work. Owner names of CNAME RRs can encode
instructions (upto 63 bytes per label including relative jmps) and the
chain would preserve order.

(2) An AAAA RR has 16 bytes of RDATA which can encode an instruction and
a relative jmp to the next RR in the RRset. This won't work if the RRset
is reordered via cache.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160224/989ceb34/attachment.sig>

More information about the dns-operations mailing list