Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: [Wireshark-dev] Clang build with ASAN

From: Alexis La Goutte <alexis.lagoutte@xxxxxxxxx>
Date: Mon, 12 Aug 2013 17:17:50 +0200
Hi,

it is now possible to build wireshark with clang (CC=clang ./configure && make) (i fix last issue last week end).


I will try the ASAN feature ( http://clang.llvm.org/docs/AddressSanitizer.html )


I try to fuzz some capture from menagerie but i have already a issue with editcap (libwiretap)

./editcap -E 0.5 ../menagerie/public/10014-packet-mount-len.pcap /tmp/fuz.pcap |& ./asan_symbolize.py
=================================================================
==15448==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff7e959c70 at pc 0x43a0d3 bp 0x7fff7e959890 sp 0x7fff7e959050
READ of size 112 at 0x7fff7e959c70 thread T0
    #0 0x43a0d2 in memcpy ??:0
    #1 0x7faee0ab0f8d in ?? ??:0
    #2 0x7faee1667a7a in pcapng_dump_open wireshark/wiretap/pcapng.c:3631
    #3 0x7faee160b254 in wtap_dump_open_finish wireshark/wiretap/file_access.c:1507
    #4 0x45ceb1 in main wireshark/editcap.c:1205
    #5 0x7faedfea876c in ?? ??:0
    #6 0x45aeec in _start ??:0
Address 0x7fff7e959c70 is located in stack of thread T0 at offset 560 in frame
    #0 0x7faee166679f in pcapng_dump_open wireshark/wiretap/pcapng.c:3593
  This frame has 10 object(s):
    [32, 40) 'bh.i2'
    [96, 104) 'idb.i'
    [160, 164) 'zero_pad.i3'
    [224, 228) 'option_hdr.i4'
    [288, 296) 'bh.i'
    [352, 368) 'shb.i'
    [416, 420) 'zero_pad.i'
    [480, 484) 'option_hdr.i'
    [544, 560) 'interface_data'
    [608, 720) 'int_data'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
Shadow bytes around the buggy address:
  0x10006fd23330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006fd23340: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 f4 f4 f4
  0x10006fd23350: f2 f2 f2 f2 00 f4 f4 f4 f2 f2 f2 f2 04 f4 f4 f4
  0x10006fd23360: f2 f2 f2 f2 04 f4 f4 f4 f2 f2 f2 f2 00 f4 f4 f4
  0x10006fd23370: f2 f2 f2 f2 00 00 f4 f4 f2 f2 f2 f2 04 f4 f4 f4
=>0x10006fd23380: f2 f2 f2 f2 04 f4 f4 f4 f2 f2 f2 f2 00 00[f4]f4
  0x10006fd23390: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006fd233a0: 00 00 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00
  0x10006fd233b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006fd233c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006fd233d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
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
  ASan internal:         fe
==15448==ABORTING

I known is may be a false positive... (and i not a expert in memory stuff...)

Also may be now add a clang build to buildbot? (no only scan-build)