[Tcpick-project] tcpick 0.2.1 segfault condition (fwd)
Status: Beta
Brought to you by:
duskdruid
Menu
▾
▴
[Tcpick-project] tcpick 0.2.1 segfault condition (fwd)
|
From: Andrea B. <an...@in...> - 2006-03-20 09:49:10
|
The maintainer is unresponsive (and his main email address bounces) so I'm forwarding this to tcpick mailing list. Preliminary analysis from the Gentoo Security Team showed that it's unlikely to be easily exploitable, but we didn't perform a full audit. Nonetheless this needs patching. Bye and thanks ----- Forwarded message from Andrea Barisani <an...@in...> ----- Date: Wed, 8 Mar 2006 17:05:34 +0100 From: Andrea Barisani <an...@in...> To: dus...@de... Cc: ro...@in..., sec...@ge..., lc...@ge... Subject: tcpick 0.2.1 segfault condition Mail-Followup-To: dus...@de..., ro...@in..., sec...@ge... Hi Francesco, we've found a segfault condition in tcpick, considering that this is a sniffer and that it can be triggered remotely this is a serious bug and security concern. We would like to coordinate with you an advisory release and a possible fix for this privately before going public. I have found this with my FTester (http://dev.inversepath.com/trac/ftester) with the following conf: flags: -g 3 -e frag3 -s 1 -d 0.01 -F ids-conn=10.1.7.1:1025-1026:10.1.7.3:443:PA:TCP:0:/etc/shadow fragmented packets (with possibly bad headers even if I can't spot where exactly) cause tcpick to segfault, here's what happens: # tcpick -a -yP -i eth0 -n Starting tcpick 0.2.1 at 2006-03-08 16:20 CET Timeout for connections is 600 tcpick: listening on eth0 1 SYN-SENT 10.1.7.1:1025 > 10.1.7.3:443 seqprobe ;............1.7.1.10.in-addr.arpa..... .8...........1.7.1.10.in-addr.arpa..... ;............1.7.1.10.in-addr.arpa.............)..A.prisoner.iana.org. hostmaster.root-servers.AwT........... :.. :. e............3.7.1.10.in-addr.arpa..... 1 SYN-RECEIVED 10.1.7.1:1025 > 10.1.7.3:443 e............3.7.1.10.in-addr.arpa.............)..A.prisoner.iana.org. hostmaster.root-servers.AwT........... :.. :. .8...........1.7.1.10.in-addr.arpa................A.pr .............3.7.1.10.in-addr.arpa..... .............3.7.1.10.in-addr.arpa............. ..A.pr /etc /etc...10.in-addr.arpa............. ..A.prisoner.iana.org. ...4....ii.... .......!...//lib.libnss_dns.so.2.......!...//lib/libresolv.so.2........!...//lib.libresol v.so.2............h....;......h....;..).......h....;...1..........h....;...1..!...x........ ............... .......10.1.7.3....................!...//lib.libnss_files.so.2. sea!........;...1.......... .;...1......_...`L......................!...//lib/libnss_dns.so.2... ...............passwd.. ....1...................................files...........8.......shadow......1............... ....................files...4...........P...group.......1................................... files...... .........................Segmentation fault # You can clearly see some memory there. Here's a gdb trace: GNU gdb 6.2.1 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "//lib/libthread_db.so.1". (gdb) run -a -Y -yP -n -i eth0 "not port 22" Starting program: ./tcpick-0.2.1/src/tcpick -a -yP -n -i eth0 "not port 22" Starting tcpick 0.2.1 at 2006-03-08 16:27 CET ... Program received signal SIGSEGV, Segmentation fault. out_p (out=0xb7f8d5e0, buf=0x808b000 <Address 0x808b000 out of bounds>, buflen=-133301) at display.c:216 216 if( ( isascii( CHAR ) && !iscntrl( CHAR ) ) || (gdb) bt #0 out_p (out=0xb7f8d5e0, buf=0x808b000 <Address 0x808b000 out of bounds>, buflen=-133301) at display.c:216 #1 0x0804aa26 in got_packet (useless=0x0, hdr=0xbf9a6e60, packet=0x806a722 "") at loop.c:119 #2 0x0804c245 in pcap_read_linux () #3 0x0804d337 in pcap_loop () #4 0x0804b09f in main (argc=7, argv=0xbf9a6fe4) at tcpick.c:264 (gdb) If we look at loop.c we see that you are trusting the packet headers for setting payload_len. Having something like buflen-- in display.c without any form of boundary checks doesn't help here. I'm also attaching a dump that you can safely inject with tcprelay while sniffing in order to see the segfault. Please let me know how would you like to handle this and preferred dates/embargo_date for release. Cheers -- Andrea Barisani Inverse Path Ltd Chief Security Engineer -----> <-------- <an...@in...> http://www.inversepath.com 0x864C9B9E 0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E "Pluralitas non est ponenda sine necessitate" ----- End forwarded message ----- |
