Tracing Bugs in Wireshark

So word spread pretty quickly about the wireshark bugs being thrown around Defcon 20 CTF. After I got my hands on acme pharms packet capture I quickly set out to recover the evil packets and weaponize them :)

After unpacking the tarball I found a pcap file that crashed my Wireshark(version 1.8.1), sf1-37.pcap

My copy of Wireshark was compiled without any debug information so I quickly grabbed the latest source from and recompiled it. After opening the pcap again in a Wireshark session running under gdb I got the name of the source file and even the offending line of code.

Wireshark state information at crash

The source of the crash is a division by zero. Perfect for crashing Wireshark.

I wanted to examine this packet in Wireshark so I needed to write a patch and recompile.

I rewrote the line

rx_min = c_max * rsk / plen;


     puts("error in dcp-etsi.c");
     rx_min = c_max * rsk / plen;

I was able to quickly hunt down the offending packets in wireshark. There are several hundred of them. They are easily identifiable because wireshark says they need l337:

Need 1337

I exported the first one that caught my fancy to see if I could induce a wireshark crash with a single packet.

As it turns out, you can. Sweet. This makes my life easy, I can strip out the application layer data from this packet to write a POC.

Writing a script to exploit this bug is easy. I used scapy, a third party packet crafting python library to build an IPv6 packet with one argument for a destination IPv6 address and send it.

#Evan Jensen AKA wont
#divide by zero in dcp-etsi.c wireshark dissector. Unpatched at time of publish
from scapy.all import *
from sys import *


if len(argv)<2:
    print "open lol.pcap"


This entry was posted in 0day, Bugs, CTF. Bookmark the permalink.

One Response to Tracing Bugs in Wireshark

  1. Pingback: Week 31 in Review – 2012 | Infosec Events

Leave a Reply