POLY SYSTEMS - GNU GLIBC DNS IMPACT

WORKAROUND

An effective mitigation strategy will incorporate techniques both within the product configuration and in the deployment architecture. Poly recommends additional network and architectural mitigations in all cases, including (but not limited to): Configure your Poly products to use trusted DNS resolvers. Use IP addresses rather than names where possible. Protect your systems from corrupted outside DNS servers or addresses via network firewalling and separation to limit or block untrusted DNS lookups from Poly devices. Protect your Poly systems from unauthorized access with named accounts, complex passwords and by controlling network access to administrative functions.

The vulnerability relies on an oversized (2048+ bytes) UDP or TCP DNS response, which is followed by another response that will overwrite the stack. An effective mitigation would be to limit the response sizes accepted by the DNS resolver called upon by your Poly devices (e.g., via DNSMasq or similar software deployed locally on the resolver).

In a default libresolv configuration, the UDP-based vector will be mitigated by using a trusted, protocol-compliant DNS resolver on a trusted network. A compliant resolver will not produce the kind of oversized responses which are necessary to exploit this vulnerability. By default, the glibc resolver does not enable EDNS0 and does not request large responses. Ensure that DNS queries are sent only to DNS servers which limit the response size for UDP responses with the truncation bit set.

The buffer size configuration option offered by most resolvers only applies to UDP not TCP. The TCP-based vector can be mitigated by using a trusted recursive resolver on a trusted network, if you limit the size of individual DNS responses to 1023 bytes, however we recognize this is non-standard.