<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi everybody,<br>
<br>
Awhile back I found a bug in Dig with the combination of the
'+nssearch' and '+tcp' flag.
(<a class="moz-txt-link-freetext" href="https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1258003">https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1258003</a>)<br>
It has since been patched.<br>
<br>
I've come across another bug/vulnerability. From what I can tell,
it's a null pointer bug.<br>
<br>
Using the +nssearch and +tcp flags together, when looking at a
domain with an ipv6 address, Dig crashes with a segmentation fault.<br>
<br>
<br>
<blockquote type="cite">130 0j 09:26:23 (root@limehost)
~/bind9/bin/dig # ./dig -v<br>
DiG 9.11.0pre-alpha<br>
0 0j 09:26:25 (root@limehost) ~/bind9/bin/dig # ./dig +time=3
+nssearch +tcp internot.info<br>
;; Connection to
2400:cb00:2049:1::adf5:3a68#53(2400:cb00:2049:1::adf5:3a68) for
internot.info failed: network unreachable.<br>
Segmentation fault<br>
</blockquote>
<br>
The computer I'm running on does not have an ipv6 IP address.<br>
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.<br>
<br>
I'm guessing it's the dig program, though.<br>
<br>
Here is the output from in gdb:<br>
<blockquote type="cite">[New Thread 0x7ffff5a4f700 (LWP 37278)]<br>
[New Thread 0x7ffff524e700 (LWP 37279)]<br>
[New Thread 0x7ffff4a4d700 (LWP 37280)]<br>
;; Connection to
2400:cb00:2049:1::adf5:3a68#53(2400:cb00:2049:1::adf5:3a68) for
internot.info failed: network unreachable.<br>
<br>
Program received signal SIGSEGV, Segmentation fault.<br>
[Switching to Thread 0x7ffff5a4f700 (LWP 37278)]<br>
bringup_timer (default_timeout=10, query=<optimised out>) at
dighost.c:2733<br>
2733 if (ISC_LIST_NEXT(query, link) != NULL)<br>
</blockquote>
<br>
<blockquote type="cite">(gdb) up<br>
#1 0x0000000000415f84 in connect_done (task=<optimised
out>, event=0x0) at dighost.c:3239<br>
3239 bringup_timer(next, TCP_TIMEOUT);<br>
</blockquote>
<br>
<blockquote type="cite">(gdb) print next<br>
$1 = (dig_query_t *) 0xffffffffffffffff<br>
</blockquote>
<br>
0xffffffffffffffff is -1.<br>
<br>
bringup_timer is as followed:<br>
<blockquote type="cite">bringup_timer(dig_query_t *query, unsigned
int default_timeout) {<br>
[......]<br>
if (ISC_LIST_NEXT(query, link) != NULL)<br>
local_timeout = SERVER_TIMEOUT;<br>
else {<br>
if (timeout == 0)<br>
local_timeout = default_timeout;<br>
else<br>
local_timeout = timeout;<br>
}</blockquote>
<br>
<br>
It does not have a if(query == NULL), as it is assumed from when it
is called, that check has already been made:<br>
<br>
<blockquote type="cite">3232 l =
query->lookup; <br>
3233 if (l->current_query !=
NULL) <br>
3234 next =
ISC_LIST_NEXT(l->current_query, link); <br>
3235
else <br>
3236 next =
NULL; <br>
3237
clear_query(query); <br>
3238 <b>if (next != NULL)
{ </b><br>
3239 <b>bringup_timer(next, TCP_TIMEOUT);</b>
<br>
3240
send_tcp_connect(next); <br>
3241 } else <br>
</blockquote>
<br>
Although it checks "if (next != NULL) { ", it does not check
-1.<br>
<br>
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.<br>
<br>
I can't find the origin of ISC_LIST_NEXT, but it would seem that it
does not handle -1 properly.<br>
<br>
I'm not exactly sure where I need to report this, but I may as well
do it in this mailing list.<br>
<br>
I'm not sure if this is really severe enough for a CVE-ID or not,
but let me know about it anyways.<br>
<br>
<br>
Thanks,<br>
<br>
Joshua Rogers<a class="moz-txt-link-rfc2396E" href="https://internot.info/"><https://internot.info/></a><br>
</body>
</html>