Stuart Henderson <[email protected]> writes: > On 2015/04/12 20:19, Jérémie Courrèges-Anglas wrote: >> Eric Lalonde <[email protected]> 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!
I read the source a bit more and yup, it stinks. Eric, sorry if you did put efforts in the previous diff, but I don't think that only fixing the *obvious* runtime problems is enough. Any other oks to delete it? -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
