some iodine traffic managed to crash the PassiveDNS daemon for me, both the release 1.2.1 as well as the current git HEAD (c411c46a66f9ff31e93416984162bc5ff2da5406):
$ gdb -- passivedns/src/passivedns
[…]
Reading symbols from passivedns/src/passivedns...
(No debugging symbols found in passivedns/src/passivedns)
(gdb) r -r ./dns-minimal-for-crash-anonymized.pcap -X T -l ./passivedns.crash.log -L ./passivedns.crash.log
Starting program: …/PassiveDNS-Crashes/passivedns/src/passivedns -r ./dns-minimal-for-crash-anonymized.pcap -X T -l ./passivedns.crash.log -L ./passivedns.crash.log
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[*] PassiveDNS 1.2.1
[*] By Edward Bjarte Fjellskål <edward.fjellskaal@gmail.com>
[*] Using libpcap version 1.10.0 (with TPACKET_V3)
[*] Using ldns version 1.7.1
[*] Reading from file ./dns-minimal-for-crash-anonymized.pcap
Program received signal SIGSEGV, Segmentation fault.
ldns_rr_get_type (rr=0x55555500317c) at ../../rr.c:937
937 ../../rr.c: No such file or directory.
(gdb) bt
#0 ldns_rr_get_type (rr=0x55555500317c) at ../../rr.c:937
#1 0x000055555555b4f0 in cache_dns_objects ()
#2 0x000055555555c434 in dns_parser ()
#3 0x0000555555559554 in got_packet ()
#4 0x00007ffff7f70f6f in pcap_offline_read (p=p@entry=0x5555555eba80, cnt=cnt@entry=-1, callback=callback@entry=0x555555559270 <got_packet>, user=user@entry=0x0) at ./savefile.c:654
#5 0x00007ffff7f5cad8 in pcap_loop (p=0x5555555eba80, cnt=-1, callback=0x555555559270 <got_packet>, user=0x0) at ./pcap.c:2897
#6 0x0000555555556b30 in main ()
(gdb)
dns-minimal-for-crash-anonymized.pcap: This is an anonymized version of the originally captured traffic causing the crash, too.
dns-minimal-for-crash-anonymized-no-crash.pcap: This is my first try at anonymizing the originally captured traffic causing the crash, but doesn't cause the crash. The difference is not in the DNS payload but just in the example IP address used for anonymization. Which makes me wonder what actually causes the crash.
Anonymization in both cases done by changing the source and destination address with tcprewrite as well as the domain used in the DNS request and response using sed.
You can trigger the crash without gdb as follows:
passivedns/src/ppassivedns -r ./dns-minimal-for-crash-anonymized.pcap -X T -l ./passivedns.crash.log -L ./passivedns.crash.log
[*] PassiveDNS 1.2.1
[*] By Edward Bjarte Fjellskål <edward.fjellskaal@gmail.com>
[*] Using libpcap version 1.10.0 (with TPACKET_V3)
[*] Using ldns version 1.7.1
[*] Reading from file ./dns-minimal-for-crash-anonymized.pcap
[1] 29372 segmentation fault (core dumped) passivedns/src/passivedns -r ./dns-minimal-for-crash-anonymized.pcap -X T -l
OS: Debian 11 Bullseye (current stable), amd64
ldns: 1.7.1-2+b1 installed via apt from the Debian APT repos.
P.S.: This looks similar to #121 on a first glance, but seems to be at some completely different place in the code. Oh, and please tell me if this is an issue which should rather be reported to the ldns library.
Hi,
some iodine traffic managed to crash the PassiveDNS daemon for me, both the release 1.2.1 as well as the current git HEAD (c411c46a66f9ff31e93416984162bc5ff2da5406):
Attached is a file dns-minimal-for-crash-anonymized.zip containing two anonymized PCAP files (Github didn't let me upload them directly):
dns-minimal-for-crash-anonymized.pcap
: This is an anonymized version of the originally captured traffic causing the crash, too.dns-minimal-for-crash-anonymized-no-crash.pcap
: This is my first try at anonymizing the originally captured traffic causing the crash, but doesn't cause the crash. The difference is not in the DNS payload but just in the example IP address used for anonymization. Which makes me wonder what actually causes the crash.Anonymization in both cases done by changing the source and destination address with
tcprewrite
as well as the domain used in the DNS request and response usingsed
.You can trigger the crash without
gdb
as follows:OS: Debian 11 Bullseye (current stable), amd64 ldns: 1.7.1-2+b1 installed via
apt
from the Debian APT repos.P.S.: This looks similar to #121 on a first glance, but seems to be at some completely different place in the code. Oh, and please tell me if this is an issue which should rather be reported to the
ldns
library.