GitLab

[As reported by Jan Žižka jan.zizka@nokia.com to the security-officer@isc.org address:]

Hi,

we have been running one of the Codenomicon test suits sending various DNS responses back to client requests triggered by nslookup and dig and we have hit an abort() with reposnse containing SIG0 answer type and SIG0 type in additional records.

Domain Name System (response)
   Transaction ID: 0x2f83
   Flags: 0x8100 Standard query response, No error
   Questions: 1
   Answer RRs: 1
   Authority RRs: 1
   Additional RRs: 1
   Queries
       dns.suite.local: type A, class IN
           Name: dns.suite.local
           [Name Length: 15]
           [Label Count: 3]
           Type: A (Host Address) (1)
           Class: IN (0x0001)
   Answers
       la\030el: type SIG, class IN
           Name: la\030el
           Type: SIG (security signature) (24)
           Class: IN (0x0001)
           Time to live: 3600
           Data length: 35
           Type Covered: Unused (0)
           Algorithm: RSA/SHA1 (5)
           Labels: 85
           Original TTL: 0 (0 seconds)
           Signature Expiration: Jun  8, 1970 13:43:44.000000000 CET
           Signature Inception: Jan 16, 2019 13:45:51.000000000 CET
           Key Tag: 0
           Signer's name: dns.suite.local
           Signature: 6c00
   Authoritative nameservers
       dns.suite.local: type A, class IN, addr 0.0.0.0
           Name: dns.suite.local
           Type: A (Host Address) (1)
           Class: IN (0x0001)
           Time to live: 3600
           Data length: 4
           Address: 0.0.0.0
   Additional records
       suite.local: type SIG, class IN
           Name: suite.local
           Type: SIG (security signature) (24)
           Class: IN (0x0001)
           Time to live: 3600
           Data length: 35
           Type Covered: Unused (0)
           Algorithm: RSA/SHA1 (5)
           Labels: 0
           Original TTL: 0 (0 seconds)
           Signature Expiration: Feb  7, 1970 23:13:20.000000000 CET
           Signature Inception: Jan 16, 2019 13:45:51.000000000 CET
           Key Tag: 72
           Signer's name: dns.suite.local
           Signature: 6c00

Seems that getsection() doesn't know how to handle this kind of packet as there is already sig0 record and free_name is left 'true'.

Stack trace of thread 8334:

#0  0x00007fb9b0ad153f __GI_raise (libc.so.6)
#1  0x00007fb9b0abb895 __GI_abort (libc.so.6)
#2  0x00007fb9b147efea isc_assertion_failed (libisc.so.169)
#3  0x00007fb9b160de30 getsection (libdns.so.1102)
#4  0x00007fb9b160e3e2 dns_message_parse (libdns.so.1102)
#5  0x000000000041bff5 recv_done (dig)
#6  0x00007fb9b14b0b72 dispatch (libisc.so.169)
#7  0x00007fb9b14b0ecf run (libisc.so.169)
#8  0x00007fb9b0fde58e start_thread (libpthread.so.0)
#9  0x00007fb9b0b966a3 __clone (libc.so.6)

I have made a reproducer script (attached) it will work on Fedora 29 out of box with bind 9.11.4-P2-RedHat-9.11.4-13.P2.fc29.

I have also tried to configure named to forwarding configuration and used simple script to send the problematic response back but I have not able to force the same code path in getsection(). Still I feel this problem could hit also named and cause it to abort(). Therefore I wanted to report this through this channel first just to make sure.

I didn't manage to figure out any proper fix, I can do that locally with some check for this specific condition but I don't feel it is right. Better if someone from bind developers would have a look.

Just to make sure I'm also attaching logs from reproducer run locally and the pcap capture of the packets, in case the reproducer script fails for you.

-Jan

reproduce.sh

reproduce.pcap

reproduce.log

server.py