[CVE-2020-8622] A truncated TSIG response can lead to an assertion failure

On Support #16800 a customer reports to us:

There is a bug that we've seen in BIND, where a crash can occur if BIND receives a response to a TSIG-signed packet where the TSIG record is not completely (or at all) contained in the response which is at least 4097 bytes and the packet is marked as truncated (tc bit == 1).

We initially saw it in a 9.9 version, but then updated to an ESV 9.11 and have reproduced the issue there as well. Our 9.9 stack trace is corrupted, but we were able to get a stack trace from 9.11.

#0 0x000000fff63010c0 in raise () from /lib64/libc.so.6
#1 0x000000fff6303060 in abort () from /lib64/libc.so.6
#2 0x000000aaab8ad8b8 in assertion_failed ()
#3 0x000000fff6b12ac8 in isc_assertion_failed () from /lib64/libisc.so.169
#4 0x000000fff6e8a228 in dns_message_checksig () from /lib64/libdns.so.1102
#5 0x000000fff6f4c2b0 in resquery_response () from /lib64/libdns.so.1102
#6 0x000000fff6b3fcd0 in run () from /lib64/libisc.so.169
#7 0x000000fff6847e24 in start_thread () from /lib64/libpthread.so.0
#8 0x000000fff6418f2c in __thread_start () from /lib64/libc.so.6

A key element appears to be that even though BIND issues an OPT record requesting a packet size of 4096, if:

• The initial request has a TSIG.
• The responder responds with more than 4096 bytes (or at least a situation where the TSIG record is not completely contained with the first 4096 bytes)
• the response is marked with the TC bit == 1.

This is also in a scenario where BIND is acting as a forwarder, though I do not know if that is relevant.