core dump with PPP messages 1 byte long.

[Darren Reed <darrenr () reed wattle id au>]

If ppp_hdlc() is called with length < 2, bad things happen.

Notably, if length == 1, handle_ppp() will be called with "length < 0".

At this point, things get ugly and print_unknown_data() tries to print
way too much data.

If ppp_hdlc() is being called with "p - 1", shouldn't the next parameter
be "length + 1" ?

Reading the code some more, it would appear that handle_ppp() needs to
be safe if "length == 0" ('nice case' from ppp_hdlc_if_print() where
caplen >=4 for PPP_ADDRESS).

Hmmm, in ppp_hdlc_if_print(), the use of length seems to be all wrong
where "caplen < len" (caplen is totally ignored.)  Surely there must
be at least something like "if (length > caplen) length = caplen;"
in there somewhere ?

Hmmm, ppp_hdlc() should check for 'snapend[-1] == 0x7e' and truncate by
one byte if true (something like "if (*(t -1) == 0x7e) t--;" would be
the go ?)

But seriously, either handle_ppp() or ppp_hdlc() need to do some length
checking to prevent mishap.  Maybe both ?

btw, there's a type inconsistency between the declaration of '*b'
and its 1st use in ppp_hdlc() - declared "u_char *" but assigned
a "u_int8_t *".  That's just nit picking :)

The particular frame that caught this problem was similar to:
00112233 44550011 22334455 0800
45000027 bec50000 fb110000 0a000000 0c000000
06a506a5 00130000
4002000b 60d12695
7e2f7e

It would appear that this is an empty PPP_VJNC packet.

Darren

Ths stack trace looks like this:
#0  0x08050958 in hex_print_with_offset (ident=0x80be1b8 "\n\t", cp=0x81d5000 <Address 0x81d5000 out of bounds>, 
length=4294967295, oset=2048)
    at print-ascii.c:151
#1  0x080509d7 in hex_print (ident=0x0, cp=0x5 <Address 0x5 out of bounds>, length=136138752) at print-ascii.c:167
#2  0x08095257 in print_unknown_data (cp=0x81d4802 "", ident=0x80be1b8 "\n\t", len=-1) at util.c:211
#3  0x0807bb60 in handle_ppp (proto=12035, p=0x81d4802 "", length=-1) at print-ppp.c:1178
#4  0x0807b8f5 in ppp_hdlc (p=0x819997d "/~", length=1) at print-ppp.c:1112
#5  0x0807b93d in handle_ppp (proto=32303, p=0x819997e "~", length=1) at print-ppp.c:1128
#6  0x0807bcde in ppp_print (p=0x819997e "~", length=1) at print-ppp.c:1226
#7  0x0806c2f1 in l2tp_print (dat=0x8199974 "@\002", length=11) at print-l2tp.c:701
#8  0x080915de in udp_print (bp=0x819996c "\006?\006?", length=11, bp2=0x8199958 "E", fragmented=0) at print-udp.c:631
#9  0x08063031 in ip_print (bp=0x8199958 "E", length=46) at print-ip.c:539
#10 0x0805dfee in ether_encap_print (ether_type=2048, p=0x8199958 "E", length=46, caplen=46, 
extracted_ether_type=0xbffff2f0) at print-ether.c:189
#11 0x0805de11 in ether_print (p=0x8199958 "E", length=46, caplen=46) at print-ether.c:142
#12 0x0805de7f in ether_if_print (h=0xbffff360, p=0x819994a "") at print-ether.c:162
#13 0x08094b65 in print_packet (user=0xbffff530 "b?\005\b", h=0xbffff360, sp=0x819994a "") at tcpdump.c:1188
#14 0x080a77a1 in pcap_offline_read (p=0x8199768, cnt=-1, callback=0x8094b1a <print_packet>, user=0xbffff530 
"b?\005\b") at savefile.c:941
#15 0x0809b70d in pcap_loop (p=0x8199768, cnt=-1, callback=0x8094b1a <print_packet>, user=0xbffff530 "b?\005\b") at 
pcap.c:96
#16 0x08094731 in main (argc=3, argv=0xbffff5a4) at tcpdump.c:997
#17 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.