Bug 76497 - tcpdump dumps core on ppp ipv6cp packets
Summary: tcpdump dumps core on ppp ipv6cp packets
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 5.3-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-01-20 12:20 UTC by Mohacsi Janos
Modified: 2008-02-09 13:12 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mohacsi Janos 2005-01-20 12:20:26 UTC
	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
Comment 1 Giorgos Keramidas freebsd_committer 2005-01-20 17:29:15 UTC
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
Comment 2 Giorgos Keramidas freebsd_committer 2005-01-20 17:36:54 UTC
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;
%%%
Comment 3 Mohacsi Janos 2005-01-20 17:42:01 UTC
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
Comment 4 matthias.andree 2005-01-20 17:50:16 UTC
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?
Comment 5 Giorgos Keramidas freebsd_committer 2005-01-20 17:59:33 UTC
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.
Comment 6 Matthias Andree 2005-01-23 17:03:01 UTC
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.
Comment 7 Bruce M Simpson freebsd_committer 2005-01-24 14:56:48 UTC
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.
Comment 8 Janos Mohacsi 2005-04-15 10:51:00 UTC
You can close this PR. It has been resolved.
Comment 9 Mark Linimon freebsd_committer freebsd_triage 2005-04-15 13:17:35 UTC
State Changed
From-To: patched->closed

Submitter notes problem has been resolved.
Comment 10 Mark Linimon freebsd_committer freebsd_triage 2005-04-15 13:19:19 UTC
State Changed
From-To: closed->patched

A subsequent poster notes that the MFC is not yet done, so I should have 
left this alone.
Comment 11 Gavin Atkinson 2007-05-01 13:47:22 UTC
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.
Comment 12 Remko Lodder freebsd_committer 2008-02-09 13:12:20 UTC
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