Bug/Vulnerability in `Dig' in latest dnsutils/bind9
Joshua Rogers
megamansec at gmail.com
Tue Oct 28 08:30:45 UTC 2014
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 at limehost) ~/bind9/bin/dig # ./dig -v
> DiG 9.11.0pre-alpha
> 0 0j 09:26:25 (root at 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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20141028/d95eeab0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20141028/d95eeab0/attachment.bin>
More information about the bind-users
mailing list