RA buffer overflow

Peter Van Epp vanepp at sfu.ca
Thu Nov 19 22:48:35 EST 2009


On Wed, Nov 18, 2009 at 03:11:44PM -0500, Matt Brewer wrote:
> Hi Carter,
> 
> I'd like to thank you for your speedy response to my last question about the direction of flows.  We're still plugging away using Argus to analyze some of our traffic, which is proving more and more interesting by the day.
> 
> However we're attempting to use Argus to analyze the DEFCON capture the flag traffic that is available for download on their website, and were having some problems.  The RA tool is only able to parse about 5000 flows before encountering a buffer overflow.  Here is the output.
> 
> Any suggestions on how to proceed? is this a problem with my libraries or RA itself?
> 
> *** buffer overflow detected ***: ra terminated
> ======= Backtrace: =========
> /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0x4c2de8]
> /lib/tls/i686/cmov/libc.so.6[0x4c1e20]
> /lib/tls/i686/cmov/libc.so.6[0x4c1558]
> /lib/tls/i686/cmov/libc.so.6(_IO_default_xsputn+0x9e)[0x44b59e]
> /lib/tls/i686/cmov/libc.so.6(_IO_vfprintf+0xe1c)[0x41f95c]
> /lib/tls/i686/cmov/libc.so.6(__vsprintf_chk+0xad)[0x4c160d]
> /lib/tls/i686/cmov/libc.so.6(__sprintf_chk+0x2d)[0x4c154d]
> ra[0x8061c1c]
> ra[0x80814c8]
> ra[0x804bd88]
> ra[0x8082e68]
> ra[0x80a16e3]
> ra[0x80a1f08]
> ra[0x804c584]
> /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x3f8b56]
> ra[0x804ab81]
> ======= Memory map: ========
> 00110000-0012c000 r-xp 00000000 08:01 12607495   /lib/libgcc_s.so.1
> 0012c000-0012d000 r--p 0001b000 08:01 12607495   /lib/libgcc_s.so.1
> 0012d000-0012e000 rw-p 0001c000 08:01 12607495   /lib/libgcc_s.so.1
> 003e2000-00520000 r-xp 00000000 08:01 12649739   /lib/tls/i686/cmov/libc-2.10.1.so
> 00520000-00522000 r--p 0013e000 08:01 12649739   /lib/tls/i686/cmov/libc-2.10.1.so
> 00522000-00523000 rw-p 00140000 08:01 12649739   /lib/tls/i686/cmov/libc-2.10.1.so
> 00523000-00526000 rw-p 00000000 00:00 0 
> 005c8000-005d2000 r-xp 00000000 08:01 12649751   /lib/tls/i686/cmov/libnss_files-2.10.1.so
> 005d2000-005d3000 r--p 00009000 08:01 12649751   /lib/tls/i686/cmov/libnss_files-2.10.1.so
> 005d3000-005d4000 rw-p 0000a000 08:01 12649751   /lib/tls/i686/cmov/libnss_files-2.10.1.so
> 00710000-00725000 r-xp 00000000 08:01 12649758   /lib/tls/i686/cmov/libpthread-2.10.1.so
> 00725000-00726000 r--p 00014000 08:01 12649758   /lib/tls/i686/cmov/libpthread-2.10.1.so
> 00726000-00727000 rw-p 00015000 08:01 12649758   /lib/tls/i686/cmov/libpthread-2.10.1.so
> 00727000-00729000 rw-p 00000000 00:00 0 
> 00a35000-00a59000 r-xp 00000000 08:01 12649743   /lib/tls/i686/cmov/libm-2.10.1.so
> 00a59000-00a5a000 r--p 00023000 08:01 12649743   /lib/tls/i686/cmov/libm-2.10.1.so
> 00a5a000-00a5b000 rw-p 00024000 08:01 12649743   /lib/tls/i686/cmov/libm-2.10.1.so
> 00b1d000-00b38000 r-xp 00000000 08:01 12608108   /lib/ld-2.10.1.so
> 00b38000-00b39000 r--p 0001a000 08:01 12608108   /lib/ld-2.10.1.so
> 00b39000-00b3a000 rw-p 0001b000 08:01 12608108   /lib/ld-2.10.1.so
> 00c84000-00c85000 r-xp 00000000 00:00 0          [vdso]
> 08048000-080ce000 r-xp 00000000 08:01 14540814   /usr/local/bin/ra
> 080ce000-080cf000 r--p 00085000 08:01 14540814   /usr/local/bin/ra
> 080cf000-080d6000 rw-p 00086000 08:01 14540814   /usr/local/bin/ra
> 080d6000-0834b000 rw-p 00000000 00:00 0 
> 0979f000-0b22d000 rw-p 00000000 00:00 0          [heap]
> b74dc000-b7707000 rw-p 00000000 00:00 0 
> b771a000-b771d000 rw-p 00000000 00:00 0 
> bfbbb000-bfc1c000 rw-p 00000000 00:00 0          [stack]
> Aborted
>   

	If you would share which file from the shmoo site you are processing 
more of us can try running ra against it and see what happens. 
	What is detecting the buffer overflow? The trace doesn't look like an
ra error output (but I'm a bit back level too which I need to correct). 
	Are .debug and .devel touched in the clients source directory (if
not you need to touch them, then 

make clobber
./configure 
make
make install

to turn on symbols and debugging in the cllient). With symbols enabled the 
trace may tell us where in ra the overflow is happening. 

Peter Van Epp



More information about the argus mailing list