Nethist buffer overflow

I was browsing the “What processes are running on the Turris router?” wiki page and noticed nethist. I’ve never seen any working traffic graphs on the router, neither through the web interface nor Android app, so decided to investigate.

It seems it crashes on startup with a segfault.

Looking at nethist.c:

#define MAX_LEN_INTERFACE_LIST 20

struct network_configuration {
	char interfaces[MAX_LEN_INTERFACE_LIST][MAX_LEN_INTERFACE_NAME];
	size_t interfaces_cnt;
};

typedef struct {
	struct network_configuration network;
} configuration;

configuration g_config;

Then:

g_config.network.interfaces_cnt = 0;

while (fgets(buffer, BUFFSIZE, f) != NULL) {
	sscanf(buffer, "%20s", name);
	newlen = strlen(name) - 1;
	name[newlen] = '\0';
	memcpy(g_config.network.interfaces[g_config.network.interfaces_cnt++], name, newlen);
}

There’s no range checking here so the buffer overflows with more than 20 network interfaces:

wc -l /proc/net/dev
27 /proc/net/dev

With the router supporting lxc containers, 20 is far too low a limit and obviously the array index should be checked against the array length.

3 Likes

Thanks for the report, we will look into that!

2 Likes

I see the fix is included in the new 3.8.2 changelog. Thanks for the swift update!

2 Likes

And as expected from reviewing the changes you made, it works perfectly now: lots of pretty graphs in the Android app!

1 Like

sorry to break in this thread, just decided I’d ask here instead of creating a new one. I have the latest firmware update, and I see messages like this

warning watchdog[]: Restarted nethist

every 10 min or something like that in system log. this may not be related to original post, but I really need help to diagnose what’s going on. Maybe it’s normal to have that process restarted in the logs, but originally I started looking in the logs because of the different annoyance, that sometimes my browser won’t resolve dns from the first time, and that magically coincides with this warning messages in the logs in time, so here I am trying to figure out if it’s all related…

I see this behauviour since the factory version or something like this. As nobody on this forum doesnt explain, why nethist is there and what it does, I just disable it, remove from watchdog and everything is fine.

I guess it somehow connected to some utility, used when you gathering/sending data or something.

Regarding DNS issue, I would more suspect kresd restarts (which should be solved in last version of Turris): /etc/init.d/resolver generates wrong resolver.pid file (Kresd)

P.S.: Turris Omnia, using collectd for graphs…

thanks for chiming in!
further lookup shows that those messages and dns hiccups coincidence was literally a coincidence. And thanks for that thread about knot issue - I can’t rely on my ISP dns and have to use my local dns, so it better be bulletproof :slight_smile:

As nobody on this forum doesnt explain, why nethist is there and what it does, I just disable it, remove from watchdog and everything is fine.

Hello,
OP mention it and it is in our documentation.
But as I can see there isn’t mention that we have nethist also on Turris Omnia. I will try to add it there.

TL;DR: Nethist is creating Turris statistics for Spectator and Android.
More informations you can find here: turris-misc/nethist at master · CZ-NIC/turris-misc · GitHub

Anyway I can see also messages about restarted nethist, I’ll ask if we can do something with it.

// So result:
Thank you for letting us know about this issue.
We’ll look into it and we’ll do something with it, because this is important topic about nethist.
Also thank you @ajb007 for it.

3 Likes

Hello,
I studied what the message means and found that:
Daemon nethist will not create an .pid file after the startup.
"watchdog" looks for this file and, if does not find it, restarts the nethist service and wrote this message.

I don’t know… can something particular be observed about the DNS hiccups? By “using my own DNS” you mean disabled forwarding? (I assume Omnia with knot-resolver.)

Anyway, for nontrivial further discussion, please, open a separate thread and mention me.

yep, I meant disable forwarding dns requests outside my omnia. there are no suspicious messages in system logs about knot, but if you’d tell me how to observe knot behavior, I’d do that and make new thread for that. Thanks for your help!