[Bug 278034] tcpdump's ip6_print can read beyond buffer end

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278034

            Bug ID: 278034
           Summary: tcpdump's ip6_print can read beyond buffer end
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: bin
          Assignee: bugs@FreeBSD.org
          Reporter: rtm@lcs.mit.edu

Created attachment 249560
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249560&action=edit
a packet trace file that causes tcpdump to read beyond the end of a buffer in
pfsync_print()

tcpdump's ip6_print() is passed the real length of the packet buffer
in the length argument. It pulls len from the packet header:


        payload_len = GET_BE_U_2(ip6->ip6_plen);
        if (payload_len != 0) {
                len = payload_len + sizeof(struct ip6_hdr);
                if (length < len)
                        ND_PRINT("truncated-ip6 - %u bytes missing!",
                                len - length);

If the header's claimed length is greater than the buffer size,
tcpdump prints a warning but then continues.

Later len (rather than length) is passed to ip_demux_print():

                        ip_demux_print(ndo, cp, len, 6, fragmented,
                                       GET_U_1(ip6->ip6_hlim), nh, bp);

and is used by some of the functions it calls as the buffer length.
For example, pfsync_print() uses this len as the limit for how far
it looks into the buffer:

        while (plen > 0) {
                if (len < sizeof(*subh))
                        break;
                ...;
                len -= sizeof(*subh);

Since this len was pulled from the packet, a broken packet can cause a
read overrun.

I've attached a demo packet that causes pfsync_print() to read past
the end of the buffer. You may need an address sanitizer or
valgrind to see the problem.

# uname -a
FreeBSD stock14 15.0-CURRENT FreeBSD 15.0-CURRENT #20
main-n268970-619e6f1f9288: Sat Mar 23 16:25:40 AST 2024    
root@stock14:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
# tcpdump --version
tcpdump version 4.99.4
libpcap version 1.10.4
OpenSSL 3.0.13 30 Jan 2024
# valgrind tcpdump -v -v -n -r - -K < tcpdump43a.dat
...
==9292== Invalid read of size 2
==9292==    at 0x22C90E: pfsync_print (src/contrib/tcpdump/print-pfsync.c:168)
==9292==    by 0x1C40EE: ip6_print (src/contrib/tcpdump/print-ip6.c:487)
==9292==    by 0x1B56BD: ethertype_print
(src/contrib/tcpdump/print-ether.c:628)
==9292==    by 0x1B5121: ether_common_print
(src/contrib/tcpdump/print-ether.c:391)
==9292==    by 0x1B5213: ether_print (src/contrib/tcpdump/print-ether.c:448)
==9292==    by 0x1B5213: ether_if_print (src/contrib/tcpdump/print-ether.c:464)
==9292==    by 0x18C30E: pretty_print_packet (src/contrib/tcpdump/print.c:417)
==9292==    by 0x225D00: print_packet (src/contrib/tcpdump/tcpdump.c:3139)
==9292==    by 0x48ACC9D: pcap_offline_read (in /lib/libpcap.so.8)
==9292==    by 0x48AB248: pcap_loop (in /lib/libpcap.so.8)
==9292==    by 0x2240AC: main (src/contrib/tcpdump/tcpdump.c:2581)
==9292==  Address 0x5a3ce90 is 0 bytes after a block of size 1,024 alloc'd
==9292==    at 0x484CDB4: malloc (vg_replace_malloc.c:446)
==9292==    by 0x48AF550: pcap_check_header (in /lib/libpcap.so.8)
==9292==    by 0x48AC9E2: pcap_fopen_offline_with_tstamp_precision (in
/lib/libpcap.so.8)
==9292==    by 0x48AC8DD: pcap_open_offline_with_tstamp_precision (in
/lib/libpcap.so.8)
==9292==    by 0x2235EF: main (src/contrib/tcpdump/tcpdump.c:2079)

-- 
You are receiving this mail because:
You are the assignee for the bug.