CVE-2015-7547 was publicly released by Google yesterday and many people are wondering how it impacts them. We’ve seen many conversations like the one between @SwiftOnSecurity and @davidu, our founder:
@SwiftOnSecurity @MalwareTechBlog Not likely. Should be truncated or thrown out. We strive to avoid TCP for many reasons, this being one.
— ☁ David Ulevitch ☁ (@davidu) February 16, 2016
The good news is that if you are using OpenDNS, you aren’t affected. If you want the technical details of why, please read on as we dive a little into how we process a DNS response.
—
To start off with, OpenDNS and our DNS software, opendnscache, do not rely on glibc for name resolution. This system library provides the underlying functionality expected of many programs, including name resolution via the getaddrinfo function. Instead these calls are normally leveraged by the software talking to OpenDNS to get an answer. So it is up to us to make sure that maliciously crafted responses are blocked before they reach you.
In the case of this exploit we do this by carefully reading the packet off the wire. The first step of this is getting the correct size for the packet. For UDP packets we do this using a `recv()` call that will only accept up to the buffer size we allocate. For TCP connections, we read 2 bytes, `malloc()` a buffer according to that size, then copy that number of bytes onto the new buffer. No swaps between stack & heap are done; opendnscache itself is safe.
That makes sure we have the right buffer size from the get go, but what prevents us from passing this garbage packet on to the end user? opendnscache does a number of validity checks on every packet. It checks to see if a packet attempts to overflow its size in every operation we do. If any malformed data is detected, we simply drop the packet; it never goes into our cache.
We also don’t store raw packets. We parse the answers and store only those records. The trailing junk on the exploited packet make reading in the packets the most dangerous portion. So if the packet managed to be well-formed, opendnscache would cache only the valid answers, not the junk at the end of the packet.
Based on the initial reading of the report from Google and our own tests, opendnscache rejects these responses as malformed.
