tcpdumps dumps core on the ip6cp packets. On FreeBSD 5.3 the ip6cp packet dumps core while on FreeBSD 4.9 says: 07:34:56.393507 PPPoE [ses 0xddfb] FreeBSD 5.3 uses: tcpdump 3.8.3 FreeBSD 4.9 uses: tcpdump 3.7.2 probably this has been already reported in pr=71453 Fix: Import basic ipv6cp support from: http://cvs.tcpdump.org/cgi-bin/cvsweb/tcpdump/print-ppp.c?r1=1.102&r2=1.103 How-To-Repeat: Try to read into the tcpdump the attached uuencoded ip6cp packet. begin 644 ip6cp_packet MU,.RH0(`!````````````/__```!````$%'O02,!!@`\````/``````"/SM! M^@`*0DOL'(AD$0#=^P`0@%<!`0`.`0H``````````0`````````````````` *```````````````` ` end
On 2005-01-20 13:14, Janos Mohacsi <mohacsi@niif.hu> wrote: > Try to read into the tcpdump the attached uuencoded ip6cp packet. > > begin 644 ip6cp_packet > MU,.RH0(`!````````````/__```!````$%'O02,!!@`\````/``````"/SM! > M^@`*0DOL'(AD$0#=^P`0@%<!`0`.`0H``````````0`````````````````` > *```````````````` > ` > end True! This makes tcpdump segfault in CURRENT too. Building an unstripped, debug version of tcpdump gives: % (gdb) bt % #0 0x00000000 in ?? () % #1 0x0806d194 in handle_ctrl_proto (proto=32855, pptr=0x8184018 "\001\001", length=14) % at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ppp.c:447 % #2 0x0806e477 in handle_ppp (proto=0, p=0x8184018 "\001\001", length=14) % at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ppp.c:1064 % #3 0x0806e5fb in ppp_print (p=0x8184018 "\001\001", length=14) % at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ppp.c:1146 % #4 0x0806eac0 in pppoe_print (bp=0x8184010 "\021", length=46) % at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-pppoe.c:212 % #5 0x0805aacf in ether_encap_print (ether_type=34916, p=0x8184010 "\021", length=46, caplen=46, extracted_ether_type=0xbfbfe73a) % at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ether.c:257 % #6 0x0805a5e1 in ether_print (p=0x8184010 "\021", length=46, caplen=46) % at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ether.c:142 % #7 0x0805a723 in ether_if_print (h=0x0, p=0x8184002 "") % at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ether.c:162 % #8 0x08083724 in print_packet (user=0x0, h=0xbfbfe7e0, sp=0x8184002 "") % at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1010 % #9 0x280d69a6 in pcap_offline_read () from /usr/lib/libpcap.so.3 % #10 0x280e2750 in pcap_loop () from /usr/lib/libpcap.so.3 % #11 0x0808321f in main (argc=3, argv=0x80836f0) at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:803
On 2005-01-20 19:29, Giorgos Keramidas <keramida@freebsd.org> wrote: > % (gdb) bt > % #0 0x00000000 in ?? () > % #1 0x0806d194 in handle_ctrl_proto (proto=32855, pptr=0x8184018 "\001\001", length=14) > % at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ppp.c:447 The following patch fixed the crash for me. At line 444, pfunc is set to NULL for unknown types of packets, but it isn't checked against NULL at line 447, so an attempt to call a function at address NULL is made (this is shown as the address of the last function called in the stack trace above). %%% Index: print-ppp.c =================================================================== RCS file: /home/ncvs/src/contrib/tcpdump/print-ppp.c,v retrieving revision 1.13 diff -u -r1.13 print-ppp.c --- print-ppp.c 31 Mar 2004 14:57:24 -0000 1.13 +++ print-ppp.c 20 Jan 2005 17:31:33 -0000 @@ -444,7 +444,7 @@ pfunc = NULL; break; } - if ((j = (*pfunc)(tptr, len)) == 0) + if (pfunc == NULL || (j = (*pfunc)(tptr, len)) == 0) break; x -= j; tptr += j; %%%
The problem lies in the logic of the print-ppp. If it does not found a suitable protocol switch default sets the decoding function (pfunc) to NULL and then call it. The latest CVS version of print-ppp.c of tcpdump already handles ipv6cp properly and catches null pointer if unknown CP is found. On Thu, 20 Jan 2005, Giorgos Keramidas wrote: > On 2005-01-20 13:14, Janos Mohacsi <mohacsi@niif.hu> wrote: >> Try to read into the tcpdump the attached uuencoded ip6cp packet. >> >> begin 644 ip6cp_packet >> MU,.RH0(`!````````````/__```!````$%'O02,!!@`\````/``````"/SM! >> M^@`*0DOL'(AD$0#=^P`0@%<!`0`.`0H``````````0`````````````````` >> *```````````````` >> ` >> end > > True! > > This makes tcpdump segfault in CURRENT too. Building an unstripped, > debug version of tcpdump gives: > > % (gdb) bt > % #0 0x00000000 in ?? () > % #1 0x0806d194 in handle_ctrl_proto (proto=32855, pptr=0x8184018 "\001\001", length=14) > % at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ppp.c:447 > % #2 0x0806e477 in handle_ppp (proto=0, p=0x8184018 "\001\001", length=14) > % at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ppp.c:1064 > % #3 0x0806e5fb in ppp_print (p=0x8184018 "\001\001", length=14) > % at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ppp.c:1146 > % #4 0x0806eac0 in pppoe_print (bp=0x8184010 "\021", length=46) > % at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-pppoe.c:212 > % #5 0x0805aacf in ether_encap_print (ether_type=34916, p=0x8184010 "\021", length=46, caplen=46, extracted_ether_type=0xbfbfe73a) > % at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ether.c:257 > % #6 0x0805a5e1 in ether_print (p=0x8184010 "\021", length=46, caplen=46) > % at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ether.c:142 > % #7 0x0805a723 in ether_if_print (h=0x0, p=0x8184002 "") > % at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ether.c:162 > % #8 0x08083724 in print_packet (user=0x0, h=0xbfbfe7e0, sp=0x8184002 "") > % at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1010 > % #9 0x280d69a6 in pcap_offline_read () from /usr/lib/libpcap.so.3 > % #10 0x280e2750 in pcap_loop () from /usr/lib/libpcap.so.3 > % #11 0x0808321f in main (argc=3, argv=0x80836f0) at /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:803 > > Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98
Giorgos Keramidas wrote: > On 2005-01-20 13:14, Janos Mohacsi <mohacsi@niif.hu> wrote: >>Try to read into the tcpdump the attached uuencoded ip6cp packet. >> >>begin 644 ip6cp_packet >>MU,.RH0(`!````````````/__```!````$%'O02,!!@`\````/``````"/SM! >>M^@`*0DOL'(AD$0#=^P`0@%<!`0`.`0H``````````0`````````````````` >>*```````````````` >>` >>end > > True! > > This makes tcpdump segfault in CURRENT too. Building an unstripped, > debug version of tcpdump gives: Wasn't this already patched for FreeBSD 5? If so, why not just merge 5->4 or import the patch from the vendor repo?
On 2005-01-20 18:50, Matthias Andree <matthias.andree@web.de> wrote: >Giorgos Keramidas wrote: >>On 2005-01-20 13:14, Janos Mohacsi <mohacsi@niif.hu> wrote: >>> Try to read into the tcpdump the attached uuencoded ip6cp packet. >>> >>> begin 644 ip6cp_packet >>> MU,.RH0(`!````````````/__```!````$%'O02,!!@`\````/``````"/SM! >>> M^@`*0DOL'(AD$0#=^P`0@%<!`0`.`0H``````````0`````````````````` >>> *```````````````` >>> ` >>> end >> >> This makes tcpdump segfault in CURRENT too. Building an unstripped, >> debug version of tcpdump gives: > > Wasn't this already patched for FreeBSD 5? If so, why not just merge > 5->4 or import the patch from the vendor repo? The bug is there in RELENG_5 too. I had a CURRENT workstation near so I tested things on 6.X, but the HEAD revision of print-ppp.c is the same as the one on RELENG_5.
Now that bin/71453 (the older PR) has been closed as "duplicate" (that was backwards but anyways), a more immediate bug fix might be the import of http://cvs.tcpdump.org/cgi-bin/cvsweb/tcpdump/print-ppp.c?r1=1.89.2.3&r2=1.89.2.4 <http://cvs.tcpdump.org/cgi-bin/cvsweb/tcpdump/print-ppp.c?r1=1.89.2.3%26r2=1.89.2.4> which may be less intrusive.
State Changed From-To: open->patched This fix has been committed to the tcpdump port, and an appropriate fix has been committed to tcpdump in HEAD, pending MFC/MT4.
You can close this PR. It has been resolved.
State Changed From-To: patched->closed Submitter notes problem has been resolved.
State Changed From-To: closed->patched A subsequent poster notes that the MFC is not yet done, so I should have left this alone.
This was fixed by bms in src/contrib/tcpdump/print-ppp.c 1.14 and is fixed in all 6.x releases, but was never MFC'd. Somebody needs to determine if a DoS in FreeBSD 5.x tcpdump is worth fixing, and either MFC or close this PR.
State Changed From-To: patched->closed This needs MFC to RELENG_5, though I would like people facing this to encourage them to use FreeBSD-6 and/or FreeBSD-7 (preferred) since in the not too long future REL_5 will no longer be supported. Close the ticket for those reasons