Hi everybody, Awhile back I found a bug in Dig with the combination of the '+nssearch' and '+tcp' flag. (https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1258003) It has since been patched.
I've come across another bug/vulnerability. From what I can tell, it's a null pointer bug. Using the +nssearch and +tcp flags together, when looking at a domain with an ipv6 address, Dig crashes with a segmentation fault. > 130 0j 09:26:23 (root@limehost) ~/bind9/bin/dig # ./dig -v > DiG 9.11.0pre-alpha > 0 0j 09:26:25 (root@limehost) ~/bind9/bin/dig # ./dig +time=3 > +nssearch +tcp internot.info > ;; Connection to > 2400:cb00:2049:1::adf5:3a68#53(2400:cb00:2049:1::adf5:3a68) for > internot.info failed: network unreachable. > Segmentation fault The computer I'm running on does not have an ipv6 IP address. I do not have a box that actually supports ipv6, so I don't know if the bug is the fact that it can't reach 2400:cb00:2049:1::adf5:3a68, or the actual dig program. I'm guessing it's the dig program, though. Here is the output from in gdb: > [New Thread 0x7ffff5a4f700 (LWP 37278)] > [New Thread 0x7ffff524e700 (LWP 37279)] > [New Thread 0x7ffff4a4d700 (LWP 37280)] > ;; Connection to > 2400:cb00:2049:1::adf5:3a68#53(2400:cb00:2049:1::adf5:3a68) for > internot.info failed: network unreachable. > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7ffff5a4f700 (LWP 37278)] > bringup_timer (default_timeout=10, query=<optimised out>) at > dighost.c:2733 > 2733 if (ISC_LIST_NEXT(query, link) != NULL) > (gdb) up > #1 0x0000000000415f84 in connect_done (task=<optimised out>, > event=0x0) at dighost.c:3239 > 3239 bringup_timer(next, TCP_TIMEOUT); > (gdb) print next > $1 = (dig_query_t *) 0xffffffffffffffff 0xffffffffffffffff is -1. bringup_timer is as followed: > bringup_timer(dig_query_t *query, unsigned int default_timeout) { > [......] > if (ISC_LIST_NEXT(query, link) != NULL) > local_timeout = SERVER_TIMEOUT; > else { > if (timeout == 0) > local_timeout = default_timeout; > else > local_timeout = timeout; > } It does not have a if(query == NULL), as it is assumed from when it is called, that check has already been made: > 3232 l = > query->lookup; > 3233 if (l->current_query != > NULL) > 3234 next = ISC_LIST_NEXT(l->current_query, > link); > 3235 > else > 3236 next = > NULL; > 3237 > clear_query(query); > 3238 *if (next != NULL) > { * > 3239 *bringup_timer(next, > TCP_TIMEOUT);* > 3240 > send_tcp_connect(next); > 3241 } else Although it checks "if (next != NULL) { ", it does not check -1. So, the crash originates from sending a -1 through the 'next' parameter in bringup_timer(next, TCP_TIMEOUT);. It should check for <0 too, I guess. I can't find the origin of ISC_LIST_NEXT, but it would seem that it does not handle -1 properly. I'm not exactly sure where I need to report this, but I may as well do it in this mailing list. I'm not sure if this is really severe enough for a CVE-ID or not, but let me know about it anyways. Thanks, Joshua Rogers<https://internot.info/>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users