[Ntop] Fedora core buffer overflow
Burton at ntopSupport.com
Sun Aug 7 13:59:35 CEST 2005
ldd is useless - it indicates what will be loaded based on external
references in the code (read man ldd, man ld.so and man ldconfig).
Great, except it ignores libraries not part of the executable, such as those
where ntop scans a directory to do true dynamic loads...
strace is good, but noisy...
ntop does test for the loading location - on platforms where we can - and
reports it on info.html/textinfo.html.
ntop Version.....3.1.051 traceEventTemp
Configured on.....Aug 5 2005 16:21:10
Built on.....Aug 5 2005 16:42:28
libpcap version.....libpcap version 0.8.3
ntop Process Id.....13045
http Process Id.....13045
But I settle for testing ONE location not all of them. Look at the utildl.c
code (it's a special routine because it is (1) gcc only and (2) requires a
different version of the header file from the normal one).
From: ntop-bounces at unipi.it [mailto:ntop-bounces at unipi.it] On Behalf Of
Sent: Saturday, August 06, 2005 4:39 PM
To: ntop at Unipi.IT
Subject: RE: [Ntop] Fedora core buffer overflow
--On Saturday, August 06, 2005 2:51 PM -0500 Burton Strauss
<Burton at ntopSupport.com> wrote:
> ntop uses the OS' standard facilities for finding it's executables and
> library modules. This typically is . (current directory) + a bunch of
> OS/distro specific locations (path for executables, library path for
> .so files, etc.) So it may be that you have different ntop and
> libntopxxxx files and are executing different ones depending upon where
you run from.
One can use ldd to check libraries linked at load time. Do you log the
locations of libraries found dynamically after the program is started? That
can be used to check for libraries loaded from unexpected locations.
Another trick is to strace ntop and look at the paths of all files loaded.
I've done that with closed-source stuff (mostly commercial game server
binaries) to figure out its search rules.
But the best solution is still likely to be running under gdb (or its GUI
variations like ddd) to the crash and doing proper debugging.
Ntop mailing list
Ntop at unipi.it
More information about the Ntop