On 2015/04/12 20:19, Jérémie Courrèges-Anglas wrote: > Eric Lalonde <eric.c.lalo...@gmail.com> writes: > > > The below diff fixes a bug in the assumptions ntop 1.1 makes about > > terminal column widths. When ntop is run on terminals with more than 257 > > columns, the printHeader() function will write a NULL byte beyond the > > end of the progName string. While I was there I converted sprintf() to > > snprintf(), since one of the variables written to the progName string is > > osName, which is ultimately populated from the output of `sh > > config.guess` during configure. I don’t believe this method guarantees > > osName can never cause progName to overflow. The patch itself is meant > > to be minimally invasive while addressing the problem. > > I took a look at your diff, but right now ntop is completely busted on > amd64 (last update I did was on Apr 5). What architecture(s) are you > using? > > > About getting this patch upstream: I don’t see how to do that, since > > upstream has moved onto a re-write called ‘ntop-ng’. I can’t even find > > old versions of ntop there. I did look on the MASTER_SITES url. There is > > a newer version of the ntop tarball hosted there, ntop-1.2a2.tar.gz, but > > the relevant source has this issue as well. > > Given your description of the situation, I would be fine with adding > such a patch... if the existing ntop port works on amd64. :) > > Is there a reason not to move to a newer ntop release?
It's a completely different thing. It would be nice to have, but (at least as of the last version I looked at) it requires some messing about with resolvers. I'll try to remember which machine that tree is on. > > Perhaps I should just use iftop ;) > > Then perhaps we should delete ntop? ;) The current one is IMHO worse than useless and I am perfectly OK with removing it. I mean, this post here talks about sprintf and buffer overflows. It uses pcap, no privsep so it's running as root FFS!
