Package: ntop Version: 3:4.99.3+ndpi5517+dfsg2-1 Severity: grave Tags: security Justification: looks like a buffer overflow X-Debbugs-CC: deb...@cygnusnetworks.de
Running ntop under gdb. In most cases it segfaults within the first 10 seconds. # gdb /usr/sbin/ntop GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/sbin/ntop...Reading symbols from /usr/lib/debug/usr/sbin/ntop...done. done. (gdb) run -L -u ntop -P /var/lib/ntop --access-log-file=/var/log/ntop/access.log -i eth2 -p /etc/ntop/protocol.list -O /var/log/ntop -n 0 Starting program: /usr/sbin/ntop -L -u ntop -P /var/lib/ntop --access-log-file=/var/log/ntop/access.log -i eth2 -p /etc/ntop/protocol.list -O /var/log/ntop -n 0 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Tue Feb 12 18:14:59 2013 Initializing gdbm databases [New Thread 0x7fffef992700 (LWP 21289)] [New Thread 0x7fffef191700 (LWP 21290)] [New Thread 0x7fffee990700 (LWP 21291)] [New Thread 0x7fffedb43700 (LWP 21292)] [New Thread 0x7fffed342700 (LWP 21293)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffed342700 (LWP 21293)] searchFragment (actualDeviceId=0, fragmentId=41168, dstHost=0x555555b22d90, srcHost=0x555555b20fc0) at ip.c:96 96 ip.c: No such file or directory. (gdb) bt #0 searchFragment (actualDeviceId=0, fragmentId=41168, dstHost=0x555555b22d90, srcHost=0x555555b20fc0) at ip.c:96 #1 handleFragment (srcHost=srcHost@entry=0x555555b20fc0, dstHost=dstHost@entry=0x555555b22d90, sport=sport@entry=0x7fffed33f8e6, dport=dport@entry=0x7fffed33f8e8, fragmentId=41168, off=8192, packetLength=1510, dataLength=1472, actualDeviceId=0, h=0x7fffed341ca0, p=0x7fffed33fbd0 "") at ip.c:183 #2 0x00007ffff76e633e in processIpPkt (bp=0x7fffed33fbe2 "E", h=h@entry=0x7fffed341ca0, p=p@entry=0x7fffed33fbd0 "", ip_offset=18, length=length@entry=1510, ether_src=0x7fff000005b8 <Address 0x7fff000005b8 out of bounds>, ether_src@entry=0x7fffed33fb26 "", ether_dst=0x7fff00002000 <Address 0x7fff00002000 out of bounds>, ether_dst@entry=0x7fffed33fb20 "", actualDeviceId=actualDeviceId@entry=0, vlanId=vlanId@entry=10) at ip.c:1068 #3 0x00007ffff76f4ad4 in processPacket (_deviceId=_deviceId@entry=0x0, h=h@entry=0x7fffed341ca0, p=p@entry=0x7fffed33fbd0 "") at pbuf.c:1447 #4 0x00007ffff76f64de in queuePacket (_deviceId=0x0, h=0x7fffed341ca0, p=0x7fffefd48042 "") at pbuf.c:548 #5 0x00007ffff7fbcfbe in ?? () from /usr/lib/x86_64-linux-gnu/libpcap.so.0.8 #6 0x00007ffff76eec13 in pcapDispatch (_i=0x0) at ntop.c:91 #7 0x00007ffff6256b50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #8 0x00007ffff71e3a7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #9 0x0000000000000000 in ?? () (gdb) display *myGlobals.device->fragmentList 1: *myGlobals.device->fragmentList = {src = 0x0, dest = 0x1000000010, fragmentOrder = -16 '\360', fragmentId = 21845, lastOffset = 1473236608, lastDataLength = 21845, totalDataLength = 1473236288, expectedDataLength = 21845, totalPacketLength = 81, sport = 0, dport = 0, firstSeen = 5750162749747989050, prev = 0x13b771766d43882f, next = 0x35173cbb65b9e257} (gdb) display *myGlobals.device->fragmentList->next 2: *myGlobals.device->fragmentList->next = <error: Cannot access memory at address 0x35173cbb65b9e257> (gdb) display *myGlobals.device->fragmentList->prev 3: *myGlobals.device->fragmentList->prev = <error: Cannot access memory at address 0x13b771766d43882f> (gdb) Apparently the fragmentList is corrupted. Since there is no pointer magic going on the only plausible cause for this is some kind of buffer overflow. Another time the next pointer would be 0x20 or 0x50. Yet another time it came to be 0x696c00756e672d78 which by looks like "il\0ung-x" when interpreted as ascii. Surely this next pointer comes from the network. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
