Closed kohenkatz closed 1 month ago
It looks like this is a memory overflow bug.
The problem looks like it comes from this code:
struct sockaddr_in6 *addrin = (struct sockaddr_in6 *)&addr;
inaddr = (struct in_addr *)&addrin->sin6_addr;
This is casting a 128 bit IP address (type struct in6_addr
) to a 32-bit IP address (type struct in_addr
). I believe that the only reason this shows 64 bits correctly is because the compiler has aligned the struct to 64 bits of space. However, the next 64 bits contain some other variable. I haven't tested (because I don't have a 32-bit machine available), but I suspect that running a 32-bit version would only show a quarter of the address correct.
What operation system is running at the source and destination ?
I have reproduced this on several systems, all (sources and destinations) with the same OS:
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS"
$ uname -a
Linux myhostname 4.9.36-x86_64-linode85 #1 SMP Thu Jul 6 15:31:23 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
I can also reproduce this problem, getting almost identical results to you.
I'll make a PR for this issue, with and without support of sockaddr_storage
. I just need to test it before :-) @kohenkatz's analysis is right, inet_ntop
is given an addr
struct while the socket family can be AF_INET6
, making it process data outside the struct.
Wow this confused me for a while. Still present in Ubuntu 20.04 - nrpe 4.0.0-2. Possibly they aren't compiling it in the way described in the fix? Based on the date the code was merged this fix should be in that Ubuntu package, right?
@realflash I don't think the fix was ever merged into the project. The PR was closed without merging, and NRPE is no longer maintained.
When displaying an error connecting to a server with an IPv6 address, the first half of the address is shown correctly but the second half is junk.
For example, I have set up a testing NRPE installation on one of my machines using a TunnelBroker.net IPv6 tunnel. NRPE on this machine is purposely set to reject all non-localhost connections in order to illustrate this bug. The IP address in the command below is the actual IP of the machine. I will try to make sure that the tunnel stays open until this bug is resolved.
Command:
Output:
Note that the first half of the address is correct and the second half seems to be random garbage (Though it is the same random garbage every time).