+++ This bug was initially created as a clone of Bug #1193801

This is to track finding 1) from the parent bug:

1) Possibly invalid memory reference in `strnlen` call in `forward_dns_reply()`
===============================================================================

In `forward_dns_reply()` in `dnsproxy.c:2004` the following `strnlen`
invocation occurs:

```
host_len = *ptr;
if (host_len > 0)
	domain_len = strnlen(ptr + 1 + host_len,
			reply_len - header_len);
```

This function does not actually check whether there are enough `reply_len`
bytes at all to even retrieve a valid `host_len` from where `ptr` is pointing
to.

The maximum size calculation `reply_len - header_len` is not necessarily
correct. If `reply_len` is smaller than `header_len`, which can be the case
for the TCP case (see issue 2), then `reply_len - header_len` can even become
negative i.e. an underflow wrap occurs.

`host_len` can be up to 255 and is attacker controlled. This means even for
the UDP case, where the calling function does make sure that at least
`header_len` bytes are available, the `ptr + 1 + host_len` expression can
point up to 257 bytes outside of valid packet data.

For the UDP case this means that data present in the stack based buffer in
function `udp_server_event` in `dnsproxy.c:2243` will be accessed that could
contain data from previous DNS replies or stack management data (pointer
addresses, stack canary values).

For the TCP case, where a heap based buffer of the exact receive size is used
(see `dnsproxy.c:2417`) this means that a heap out of bounds read access is
performed that could even crash Connman. In my exploit tests I did not manage
to cause a crash but this depends strongly on the heap allocator and
optimization levels etc.

So the possible effects of this vulnerability are:

- undefined behaviour of the domain name uncompress / recompress handling
  based on undefined data.
- remote denial of service especially in the TCP case
- an information leak, especially in the UDP case where a stack based buffer
  is used. If an attacker controls both the DNS server and the DNS client, or
  the DNS client and can spoof DNS replies on the network, then that attacker
  could receive stack management data on the client side. This is because the
  `forward_dns_reply` function has large degrees of freedom in the dns name
  uncompress / recompress handling and will forward even undefined data to the
  DNS client.

I suggest to diligently check for sufficient input data in the
`forward_dns_reply()` function to avoid any out of bound accesses.