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

[Robert Edmonds]

Mike Hoskins (michoski) wrote:
> Fair points, though once we start down the path of "unknown unknowns"
> Donald Rumsfeld gets to smile...and we can't have that.

These aren't "unknown unknowns".

There's a "known known", that malicious payloads can be well-formed DNS
responses and traverse a cache, according to Dan Kaminsky:

    http://dankaminsky.com/2016/02/20/skeleton/

    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.

Damian's not convinced that this leads to exploitation, so feel free to
downgrade that to a "known unknown".

There's another "known known", that exploitation of the TCP path
requires forcing a retry to occur:

    https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html

    A similar exploit is possible with TCP, but requires closing the TCP
    connection (either with a TCP reset or a regular 3-way connection
    close), or sending an empty response with a zero length header. Any
    such action with forces send_vc to exit and retry with the wrong
    buffer size will trigger a similar failure as seen in send_dg.

    https://lists.dns-oarc.net/pipermail/dns-operations/2016-February/014347.html

    I'm hesistant to name specific implementations publicly (because it
    could be construed as blaming glibc's exposure on them). But we have
    encountered one implementation which does close TCP connections
    without sending responses in an overload situation.

    The relevant TCP behavior is hop-by-hop, and as such it is
    influenced by middleboxes and their connection and state management.
    This makes it difficult to make accurate statements without detailed
    knowledge of the network of interest.

If you read OpenDNS's response carefully, it says (1) We don't use
getaddrinfo() for name resolution, (2) We handle our own buffers
correctly and therefore don't have a similar vulnerability, (3) We
re-synthesize answers and thus don't pass through invalid packets like
in the Google MITM PoC.

It doesn't answer whether the TCP retry necessary for exploitation to
occur can be induced between OpenDNS and an OpenDNS client. That's much
harder to answer (see the second paragraph of Florian's message above),
but it's not an "unknown unknown".

-- 
Robert Edmonds