Bug/Vulnerability in `Dig' in latest dnsutils/bind9

[Joshua Rogers]

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>