[dns-operations] CVE-2015-7547: glibc getaddrinfo buffer overflow
edmonds at mycre.ws
Tue Feb 23 19:21:15 UTC 2016
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:
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:
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.
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".
More information about the dns-operations