rpcap support on non-windows

[Joerg Mayer <jmayer () loplof de>]

Hello,

I'm trying to get libpcap working on macOS.
With the previously sent patch I am able to build libpcap with rpcap support.
dumpcap (from Wireshark) compiles and links fine with the new version and it
does a bit of rpcap communication with my rpcap server (an AP) and after that
it segfaults. Compiling and linking (both dumpcap and libpcap) with asan gave
me the output below (after some rpcap traffic on the network).

Trying to understand the problem it looks like accessing struct pcap_md (the
rpcap specific stuff) is broken on non-win32 platforms (or at least on bpf
platforms).

The intended memory layout seems to be:

struct pcap_t (containing a pointer to priv if it exits)
priv:
struct pcap_<platform>
struct pcap_md (if compiling with HAVE_REMOTE)

The current implementation seems to

a) only allocate the memory for pcap_md on win (pcap_create_interface() in
   pcap-win32.c), thus causing an out of bounds access on other platforms.
b) the access to pcap_md is calculated as priv + sizeof(struct pcap_win)
   on all platforms which gets redeclared in pcap-new.c and pcap-rpcap.c
   for just this purpose. This looks wrong to me but I'm not sure.

Anyone willing to look into this?

Thanks
   Jörg

jmayer@newegg:~/worktmp/wireshark$ dumpcap -r -i 'rpcap://10.122.4.11/wifi0'
Capturing on 'rpcap://10.122.4.11/wifi0'
=================================================================
==45693==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61600000b158 at pc 0x00010886d3d5 bp 0x7fff57442bf0 
sp 0x7fff57442be8
WRITE of size 4 at 0x61600000b158 thread T0
    #0 0x10886d3d4 in pcap_opensource_remote pcap-rpcap.c:833
    #1 0x10886b4db in pcap_open pcap-new.c:934
    #2 0x1087ccad7 in open_capture_device capture-pcap-util.c:1322
    #3 0x1087b87aa in main dumpcap.c:2196
    #4 0x7fffd7e02254 in start (libdyld.dylib+0x5254)

0x61600000b158 is located 40 bytes to the left of 528-byte region [0x61600000b180,0x61600000b390)
allocated by thread T0 here:
    #0 0x108be0157 in wrap_calloc (libclang_rt.asan_osx_dynamic.dylib+0x4b157)
    #1 0x7fffd7512e6b in allocateBuckets(unsigned int) (libobjc.A.dylib+0x8e6b)
    #2 0x7fffd7512dfa in cache_t::reallocate(unsigned int, unsigned int) (libobjc.A.dylib+0x8dfa)
    #3 0x7fffd7512626 in cache_fill (libobjc.A.dylib+0x8626)
    #4 0x7fffd7511c3d in lookUpImpOrForward (libobjc.A.dylib+0x7c3d)
    #5 0x7fffd75115d3 in _objc_msgSend_uncached (libobjc.A.dylib+0x75d3)
    #6 0x7fffc289b94c in CFArraySortValues (CoreFoundation+0x7894c)
    #7 0x7fffc947df9d in _SCNetworkInterfaceCopyAllWithPreferences (SystemConfiguration+0xaf9d)
    #8 0x1087c9c1a in if_info_new capture-pcap-util.c:158
    #9 0x1087caa9e in get_interface_list_findalldevs capture-pcap-util.c:531
    #10 0x1087b2375 in capture_opts_add_iface_opt capture_opts.c:591
    #11 0x1087b0566 in capture_opts_add_opt capture_opts.c:794
    #12 0x1087b6acc in main dumpcap.c:4153
    #13 0x7fffd7e02254 in start (libdyld.dylib+0x5254)

SUMMARY: AddressSanitizer: heap-buffer-overflow pcap-rpcap.c:833 in pcap_opensource_remote
Shadow bytes around the buggy address:
  0x1c2c000015d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c2c000015e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c2c000015f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c2c00001600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c2c00001610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x1c2c00001620: fa fa fa fa fa fa fa fa fa fa fa[fa]fa fa fa fa
  0x1c2c00001630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c2c00001640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c2c00001650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c2c00001660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c2c00001670: 00 00 fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==45693==ABORTING
Abort trap: 6


-- 
Joerg Mayer                                           <jmayer () loplof de>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers